How to make your Labview executable writing a return code

[Sapiophile]

My executable is called by the worst application human beings have ever written, it's called EvoWare from the Swiss LabRobot manufacturer called Tecan. It's a huge pile of crap, but it's the only way to control the robot. This application also dies over and over again and it does not inform any users. If you've got expensive chemicals on the robot, you want to know at least when the robot is crashed, so you can save your chemicals. I've hardly any possibility to interact with other programs but i can send command line code. So I made an LV executable that works like a sandglass, you have to call it every few minutes from that lazy program and if it crashes and does not refresh the sandglass, it send error emails and sms and updates the database.

That's the background. There is one step where I call my LV executable with some parameters via command line from that lazy application. Because there is one dialog where the user also can press "cancel", I need to return an error integer in order to inform the callers application, so it can react on that. In short, yes I need an answer, but an integer or string is enough.

Thank you for your help!!!

[zou]

There are other ways to check if an application crashed.

Is EvoWare a command line application or Windows application?

When it crashed, does its window get closed or hung?

[wiebe@CARYA]

---

@Sapiophile wrote:

I need to return an error integer in order to inform the callers application, so it can react on that. In short, yes I need an answer, but an integer or string is enough.

---

But note that the applications 'return code' (it's exit code), is an integer, but (AFAIK) used to signal executable problems. I don't think it's common to communicate information.

Putting text on the command line (std out) is quite different. You can still output an integer, by converting it to text. So you'll always be dealing with strings.

It is of course possible that your lazy application can process both the return code integer and command line information. But I get a feeling you want the latter. The solutions would be completely different, and might very well collide.

[rolfk]

Under Unix it's not uncommon to use the return value of a command as an indication if something in the program went wrong and with that I mean something in the command utility operation not the OS being unable to execute the program. Under Windows this can be done too and is for command line tools not that uncommon, eventhough you have to query the implicit %errorlevel% variable after every command line execution for that. And to make things worse if your system happens to define an environment variable with that name it will hide this implicit errorlevel variable and make it inaccessible on the command line level.

GUI applications however very seldomly use this method to transport information to the caller. The means are there but since a GUI application predominantly is an interactive application that the user starts and terminates himself explicitly, it makes in most cases not a lot of sense to have this means of transporting extra information to a possible caller, which is almost always the user shell (Windows Explorer) and from an interactive user action. Under Windows a GUI process by default doesn't even allocate a console for the standard input, output and error.

[Sapiophile]

Thanks for your replies. To summarize, it's not possible to return any value from a labview executable to it's caller. That's also good to know, because now I can look for other ways to let the caller know about the reply from the user.

Thank all!

[wiebe@CARYA]

---

@Sapiophile wrote:

Thanks for your replies. To summarize, it's not possible to return any value from a labview executable to it's caller. That's also good to know, because now I can look for other ways to let the caller know about the reply from the user.

---

IMHO, that's a wrong conclusion.

There are ways to return an exit code, or output string on the command line. Both are far from ideal, but possible nonetheless.

We're simple trying to establish what it is you need in your situation before trying to give a solution. If we solve your problem with the exit code, it might not work as you really required a command line result. And vice versa.

What LabVIEW version are you using?

[Sapiophile]

2016 64bit on Mac or Win7, why?

[wiebe@CARYA]

---

@Sapiophile wrote:

2016 64bit on Mac or Win7, why?

---

Because 2018 has a build in command line interface.

Not sure how\if it works in a build LabVIEW executable. See cli creating_operations and cli_running_operations. I don't think it's a great match, though.

[wiebe@CARYA]

Wiresmith LabVIEW CLI could work for you. I've no experience with it, but it's made to do what you want.

I think all OOTB solutions (LV18, Wiresmith) will work more or less the same. LabVIEW does not return from the command line until the exe stops. In your case this is no problem, as the application does stop. However, this means you'll need to start your LabVIEW EXE, and then use some executable to communicate with the LabVIEW executable, over some mechanism. LV18 and Wiresmith both use TCP/IP. I've used named pipes before.