Strange issue with SystemExec

[SimpleJack]

Hi all,

Okay, this issue is really strange. I thought it would get solved with a Mass Compile, but it does not.

Some of my vi's use System Exec.....but not all exhibit this problem but they are almost identical VI's......just with a slightly different standard input.

When I first start Labview, a few of my VI's do not work properly because the System Exec file cannot find the executable I am calling. If I open the SystemExec.vi and look at the standard output, I see that it is pointing to the wrong directory. I do not specify a working directory, I just want it to use the directory the VI is called from.

To fix this issue, all I need to do is to do a "Save As" and write over the old copy of the VI. It then works.....but.....if I close Labview all together and reopen, I have the same issue.

There has to be a simple fix for this. Does anyone have it? I do not want to specify a working directory because this is going to get integrated into TestStand and then deployed.

Thanks,

Ryan

[nkeddem]

I have found this same issue.  So far I haven't found a fix.  Very annoying when a VI randomly stops functioning that had been working perfectly before.

[rolfk]

You are both running into a problem that stems from the way Windows works.

Windows was at one time based on DOS and that used a current directory value that was always set to the directory at which the DOS command prompt was set at the moment. If you wanted to access files relative to that current directory you could do without defining an absolute path. Now System Exec still uses this DOS functionality. Windows maintains a per process current directory global that is set on process startup to the directory from which the executable was started. System Exec will look for executable files in the standard Windows search locations (Windows and System directory and any directory mentioned in the PATH environment variable and also the directory specified in this current directory global variable.

And now comes the funny thing: The System File dialog sets on a successful file selection the current directory to the directory in which a file was selected. So here you go why it works after you do a Save as (but this is of course not a stable solution, especially if you have different VIs in different directories that try to call some system commands with relative paths).

The stable solution is to use the working directory input of the System Exec VI. This will in fact overwriting the current directory setting for the newly started process only so you can control exactly which directory it should use for relative files.

The whole current directory woodoo is nice for interactive command execution but obviously not something you should and can rely on for programmatic execution.

[SimpleJack]

Rolf,

Thank you for the answer. I do have one more question though. If I set the working directory, will this cause me pain if I build this VI into a TestStand Deployment package?

Thanks,

Ryan

[rolfk · Accepted solution]

The working directory input to the System Exec is only relevant for the process that gets started by System Exec to execute the system command. So no it should not have any influence on the calling process, be it LabVIEW or Test Stand.