Running console application from LV7.1 problems

[Yamaeda]

I've had similar issues that was solved by connecting "Working dir" of the system exec and set it to the .exe path.

/Y

[huntersoa]

Gave this a go + the previous comment too (run as administrator for elevated rights) but neither worked. However I think I’ve found the solution and it is quite funky to me.

There is the input “Wait for competition?” and till now I always had it on true since this is the description:

To me this clearly means that I must have it as “true”. I messed about in LV2015 to test what is up. And I accidentally set this to false -> And magic happened, it works. Even though the description states that if it is false it’d run in background. But it looks like it is the opposite….

I’ll test with this some more and if it really does work this way I’ll accept this as solution. 

[huntersoa]

So I just did a few tests aaaand. Now the text is displayed and what not. But the VI in the background finishes running before the console application -> Thus I have no return value.... Maybe I should recreate the System exec.vi and put in a wait time? Does someone have a proposal how this should be approached?

I mean I do know how long it takes for the process but a flat on wait time is not ideal -> If there are errors it might take less than 1 minute to finish. But if there are none it takes about 9 minutes…  I am not 100% sure what should be done….

[wiebe@CARYA]

As mentioned, the VI won't return anything until it is done. I think that's what is wrong. If 'wait until completion' is true, and the executable never finishes, the VI won't finish, and basically 'hang'. If it is false, the VI will return directly, but won't have any output strings.

Run in the background means it's running and the VI won't wait. 'background' might be deceptive in this context. It's not related to the ordering of windows. Both wait until completion false and true support run minimized, those options are complementary.

[wiebe@CARYA]

---

@huntersoa wrote:

I mean I do know how long it takes for the process but a flat on wait time is not ideal -> If there are errors it might take less than 1 minute to finish. But if there are none it takes about 9 minutes…  I am not 100% sure what should be done….

---

You should set "wait until completion" to true, and then wait 9 minutes. EDIT: Let the SE wait, and that will take 9 minutes (no error) or less (error)… A parallel wait won't do anything useful, it's completely unrelated to the DLL function call. If that doesn't work, something is wrong.

Is there anything else happening with regard to the executable? You mentioned TCP\IP, is LV communicating with the executable? That would explain a lot...

[huntersoa]

It's complicated (I mean what the called exe does).

I do not need a wait time if I set “wait until completion” to true. There is no option for the called exe to “run indefinitely” it will either finish in 1 minute or about 9 and than return with -1 or 0. Or if it crashes or something it returns with a random number / error code.

With this called exe nothing is communicating (not from LV at least) – it just does it’s thing and than returns a value. All the while it prints some status indicators to the command window. Basically it is a tool written in C and in regular conditions it must be run in a CMD window – it can not otherwise run. As I mentioned at the beginning it has a calling syntax in console and than displays all it’s things in the caller console window. It does communicate with some other stuff (like drivers and external hardware) but as I said it returns. It also returns if “wait until completion” is false but than LV does not see it as it “moved on” by the time the called exe is done.

After some further testing with the “wait until completion” – we think (a colleague joined ) that the “blank” window displayed is from labview and in reality the called executable is running in the background. At least based on testing. Since it does return and LV reads the return value properly.

Sorry I wanted to write some else but a few colleagues disturbed me + ran out of time for today. Haven’t had time to check what I wrote but will reply 2 days from now. (Tomorrow is national holiday)

[wiebe@CARYA]

We have to work on labor day .

[huntersoa]

Oh that is horrible. 

So we came up with a solution - though it is not LV related. We created a wrap exe that does the calling. 

For future reference if someone has a similar problem here is the C code: 

#include <stdio.h>
#include <Windows.h>


int main(int _argc, char** _argv) {
	STARTUPINFO         siStartupInfo;
    PROCESS_INFORMATION piProcessInfo;
    long unsigned int ec;

    memset(&siStartupInfo, 0, sizeof(siStartupInfo));
    memset(&piProcessInfo, 0, sizeof(piProcessInfo));

    siStartupInfo.cb = sizeof(siStartupInfo);

    CreateProcess("swd_pc.exe",       // Application name
                     GetCommandLine(),                 // Additional application arguments
                     NULL,
                     NULL,
                     FALSE,
                     CREATE_NEW_CONSOLE,
                     NULL,
                     NULL,
                     &siStartupInfo,
                     &piProcessInfo);

      // Could not start application

    // Wait until application has terminated
    WaitForSingleObject(piProcessInfo.hProcess, INFINITE);
    GetExitCodeProcess(piProcessInfo.hProcess, &ec);
    
    printf("Result: %d", ec);
    // Close process and thread handles
    CloseHandle(piProcessInfo.hThread);
    CloseHandle(piProcessInfo.hProcess);
    
    return (int)ec;
}

[wiebe@CARYA]

It wouldn't be that hard to call the same APIs form LabVIEW... Maintaining C\C++ code can be a hassle...

[huntersoa]

Well true. But most people use C here + that code is the responsibility of an other team.

I might have been a bit hasty with accepting it as solution. It might be true for the development environment that the solution works. However if I create an .exe out of it it does not work. It runs till the call of the “secondary” exe which just pops up and closes with either error code 1970799272 or 1995244200 (as return value from the console).

Even worse – in regular running condition a third application is calling the vi executable. Than it just lingers at the beginning and does nothing. It does not even generate errors just stops at the beginning….

I know it is not much like this but I hope someone has some tips J I’ll start digging stuff perhaps I find the problems / find info on how to properly explain the issue. Though I might have to open an other topic since it is probably not related to the original subject of this thread.