How to make your Labview executable writing a return code

[Sapiophile]

Hi folks,

I searched a lot in this forum to figure out how to write the return code with labview. I cannot use any DLL functions or so, it really has to be the return code (because of the caller application). Although already some people asked for that, I found no answer at the end. Any help is appreciated!

Thanks, Urs

[GerdW]

Hi Urs,

Although already some people asked for that, I found no answer at the end.

Then you surely have read those other threads on the very same problem!

In the end the conclusion mostly was: as LabVIEW is a GUI-based application it does not support returning error codes to a CLI on its own.

(There were some discussions to use some Windows API function to be able to return something to a CLI, but you better search for those threads on your own.)

[Sapiophile]

Hi Gerd,

Thank you for your help. I'm not a programmer, most of what I know is from self learning, wherefore i'm lost when it comes to basics, programming and interface principles and terms. Of what I understood, it is highly recommended to use DLLs instead of active x or command line calls with return values. Unfortunately, I can't use DLLs.

Since I started to programing with Labview, with every challenge I had, I always found a solution to solve it and got it all to work. And because Labview allows to call executables through command line and include parameters for the exe, I'm very confident that the other way is possible too (receiving values from the completed exe).

I'll look for CLI, as I don't know what it is. But your clearly saying that return code is not possible 😞

[Frozen]

CLI is short for Command Line Interface <https://en.wikipedia.org/wiki/Command-line_interface>

[Krapfen]

Hi Sapiophile, 

as far as I understand you is that, you want some response from your programm like whether there is an error or to be more specific, why/where is the error. If we are talking about the topic "error codes and exception handling". Then you can put some basic if condition,  some LEDs and text indicators as output. Thus, these output are considered as return code or error.

If I'am understanding well, you might looking for the following function, and the "return code" might be in the right side "error", "code","source out", "message".

The reason why I response as above is that I understand return code as following explanation from wikipedia

https://en.wikipedia.org/wiki/Return_code

- melonetern

[Sapiophile]

Hi Melonetern,

No, sorry, it's not about the error itself, it's about how an executable can send a value (usually it's an error code, but actually it could be anything) back to the caller.

Imagine, you use cmd.exe and you type like c:/folder/my_application.exe parm1 parm 1 and then you hit enter. once the application finishes, I would like to get back a single value, the return code, in my case an error number if the application was not successfull. But as mentioned above, this seems not be possible with the LV exe 😞

In that case, is there no other way than creating a file during the call of the executable that contains the return code? After the application finished, you have to have some commandline code that checks that file and react accordingly. 😞

[wiebe@CARYA]

---

@Sapiophile wrote:

In that case, is there no other way than creating a file during the call of the executable that contains the return code? After the application finished, you have to have some commandline code that checks that file and react accordingly. 😞

---

At some point I made a simple .NET exe for that. It would simply pass it's command line arguments to a named pipe, and then wait for results on another named pipe. In LabVIEW, simply wait for named pipe data, and when done, return data to the named pipe.

IIRC, this can even be done entirely from the command line. E.g. create a named pipe on the command line, start your exe, read the named pipe.

Not sure if that's easier then creating a file. I'd personally avoid file creation at all costs.

[Sapiophile]

Thank you for sharing your experience. Unfortunatly, I‘m not that advanced and I don‘t know how to set this up. Could you give me a simple example?

regards,

urs

[rolfk]

Yes Windows is written in such a way that GUI applications are not generally expected to return a return code at all. As soon as an application exists the message loop, Windows simply terminates the process and returns a 0 code to the caller, which usually doesn't care about this value. There are two Windows APIs that allow even a GUI process to return a specific error code but calling them from within a LabVIEW diagram is frought with troubles.

ExitProcess(int errorcode) will terminate all threads immediately without letting them cleanup so LabVIEW could leave resource and especially locks (mutexes) that are used in the application reserved or locked and then when the normal application shutdown is initiated and all the loaded DLLs are unloaded, their unloading might deadlock indefinitely because of a mutual exclusion error. For pure GUI applications that might be not such a big problem but for most LabVIEW application that use some kind of hardware drivers in one way or the other this is definitely not the case. TerminateProcess(HANDLE hProcess, int errorCode) is even worse. That effectively kills LabVIEW instantly without letting it cleanup anything. Hardware resources might remain physically locked in a state that only can be cleared by restarting Windows.

[wiebe@CARYA]

---

@Sapiophile wrote:

Thank you for sharing your experience. Unfortunatly, I‘m not that advanced and I don‘t know how to set this up. Could you give me a simple example?

---

No, such an example won't be simple ...

But seriously... It will be a lot of work to get this working. Note that my code will only get you half way...

Are you sure you absolutely require a return code? Or would a return string work? .NET executables can even return objects... Outputting a string on StrOut or StdErr is different from setting the return code, but could be a lot easier. AFAIK, that is actually a new build in feature, but I'll have to do some digging on that myself. Haven't got around to it, but if it does what I think it does, it will actually obsolete my solution.

I don't mind helping out, but helping out in the wrong direction won't be useful for both of us.

How are you going to call your executable? What application will check the return code?