I've noticed and issue with the System Exec.vi which I wanted to detail here. I will also make reference to System Exec+.vi which can be found here http://www.ni.com/example/29935/en/
I am attempting to connect to and send commands to a camera. The camera has it's own command line or shell that I can access for a faster response. After opening a connection to the camera's shell, I am using Windows APIs to send keystrokes to the shell in order to send commands to the camera. To access the camera's shell, I have written a program in C to check for a connection, open the shell, and then verify a valid connection. I am running this C program from Labview, and leaving the shell window open and minimized. In order to open a window for the camera's shell, I am running the system command:
start "name" /MIN <command> <args>
I want Labview to wait for completion of the C code (.exe file), which is the default (true) option for both System Exec.vi and System Exec+.vi while leaving the camera's shell window open and minimized. I am running Labview 2011 SP1 on Windows 7. I would also like access to the return code and stdout values provided by the System Exec.vi so I can know if my code executed without issue or not. These outputs are not provided by System Exec+.vi.
Running my C code in the command line leaves me with an open shell window and an available command promt. The "start" command in windows serves to run the command in a new window and not wait for completion.
If I run my code from labview using System Exec.vi, the System Exec call never finishes. Labview ends up waiting for the new shell window to close before it will release control of that call. This behavior is the issue, and is contrary to how the Windows command line treats the 'start' command. To reiterate, I am running code from Labview with the wait for completion condition, and this code is in turn opening another window with the do not wait for completion condition; while the code is completing (it's minimized window closes), Labview is waiting for the new window to close, escentially waiting for it to complete, despite it being opened with a do not wait condition.
Of interest is the System Exec+.vi behavior. System Exec+ behaves as I would expect, waiting for the main C code to complete, but not waiting for the additional shell window to complete. The downside to this VI call is the lack of access to return code, stdout, and stderr. System Exec.vi is locked and the block diagram for it cannot be accessed. System Exec+.vi can be accessed, but it relies on a DLL that I seem to be unable to uncompile, so I cannot attempt to edit it's functionality. It is my opinion that the System Exec.vi should behave more like the command line and System Exec+.vi when it comes to waiting for completion. My suspicion is that it is improperly looking for children of the process it creates and not looking for completion returns from the command line it is calling.
My solution: In order to get the desired result, I broke my code up into three chunks. First, I run some C code to check for a connection and do some housekeeping using System Exec, waiting for completion and returning a pass or fail condition. Then I run a short batch file using System Exec+, opening the new shell window, waiting for completion of the batch file but not waiting for the shell to close, and receiving no status on success or failure. Finally, I run the rest of the C code to check that the established connection is working using System Exec, waiting for completion and and returning a pass or fail condition.
Hopefully this post can serve in part as a bug report and in part as information for anyone else trying to do something similar. Again I reiterate that System Exec.vi does not function as I would expect, but that a workaround can be made through a combination of System Exec and System Exec+. Cheers.