Labview Terminated unexpectedly about g-cli HOT 9 CLOSED

In the end (and only by accident), I was able to "correctly" start the program .... but ...

How I started it:

1. Close LV (completely)
2. Send the command via command prompt (and command prompt becomes inactive)
3. LV opens the VI .... but does not start automatically
4. I manually start the VI - and get the expected response

Now my questions:
a) Is that the way it is supposed to work ?
b) to 1) Why do I need to fully close LV - with other LV programs running .... I would have to close them all first ?!
c) to 2) If I have a batch job - I might also consider to have different LV VIs running .... but since once a command is sent the prompt becomes inactive .... it is prohibited.
Note: an example would be (simplified version):
start x.vi parameter1 (no return expected)
start y.vi parameter2 (no return expected)
send x_questionfinished.vi (return expected)
if return then .....
d) to 3) How can I teach LV to directly start the vi with manual interaction ..... otherwise any batchjob would require my presence .... but that is exactly what I want to get rid of.

from g-cli.

Hi Mononuclear,

a,b & d) Yes this is the way it works (sort of). The command line inputs can only be set when the application (LabVIEW.exe) first launches. Therefore it will not work if LabVIEW is already running, this is a limitation of working with a program that is not intended to function in this way!

The VIs can have a flag set to run when launched to save you running it yourself. (VI Properties > Execution > Run When Opened). The demo should have this in but it is a real pain in the development environment so perhaps it has been accidentally switched off in the released version.

This can be used to call exes built in LabVIEW which would avoid this issue.

c) I'm not sure what you mean by inactive here. Once launched the command line programming that is providing the interface will continue to run unless there is an error or it receives an exit code from the LabVIEW application. You will need your VIs to provide an exit code (even if 0) for it to move through the batch file.

(also note to help with a and b the --kill switch will make sure LabVIEW is entirely gone once completed in case any save dialogs hold up the exit LabVIEW function).

I hope that answers your questions but let me know if not. I agree the documentation is a bit bare bones at the minute and a getting started guide will be nice - I'll open an issue to look at this when I can.

Also be aware that for command line inputs there is actually no need for this utility if you don't require return codes. This utility enables standard out and return codes but everything else can be done just with LabVIEW. See http://digital.ni.com/public.nsf/allkb/17C3AD70493CE0208625666A00763364

from g-cli.

Dear James,

Thanks for your reply. It seems, that your program cannot help me :-( (a,b,d). I just started using LV and grew up with a command prompt - and for many cases, it is a faster interaction for communication with the computer. I saw your above mentioned communication to LV without return .... but I need the return output. I also saw the system exec to send messages to a newly opened prompt screen .... and several questions by LV users, that sending and receiving messages from LV within the same environment is not feasible. Seems that I have to go through a python script and network commands.

On the long run, I certainly would have considered python (which i just started to learn few months ago) for optimization .... but so far, I have not figured out, how an optimized call-return sequence will look like ... and a command based approach would have helped me in a much faster way.

from g-cli.

Dear James,

a final comment: Although I am very new to Python & LV (I grew up with MSDOS and all these command base stuff and programs) - LV since 2 weeks & Python for some months - I finally got my ass up to find a better solution .... and I think, it might also solve your problems. In my case, my problem was a commercial machine controlling software with a LV interface and respective VIs - where I want to control the control software via LV flexibly in batch jobs rather than preprogrammed LV modules.

I now wrote a python interface which communicates in both directions via TCP network to LV within the same computer. It also opens the option to easily integrate other external programs for further data processing and their response to be fed back to the main control software. I am so far not sufficiently familiar to Python - but I would suspect that you could install it on top of a command prompt level and take over all command prompt features and open a path for direct and flexible communication to LV.

from g-cli.

I attached two screen shots for illustration of the LV code and the python code.

First the python code has to be started:
L5-9 establishes the connection & waits for the accept signal
L12-32 the recv_timeout module is to catch unwanted signals from LV (was just a test to clean the TCP buffer)
L35-45 sends signals, allows input from the console to be sent to LV, catch the reply from LV if wanted or thrashed (see L12-32) otherwise & terminates on input = "10"

The LV program has one Numeric input (to terminate LV if == 1), a display for received data, and an arbitrary function generator as a send back variable.

1. The numeric input is set to = 0
2. The communication to Python is established.
3. The while loop reads data from Python (if no data are coming, it creates an error which is caught till a signal comes) & terminates LV on input = 1.
4. If a signal comes from Python (=true), the case structure displays the signal and sends (always) back a code (arbitrary number).

Coming from that starting point (sending arbitrary data and at an arbitrary moment in an arbitrary direction), it is very easy to implement a much more sophisticated interaction.

from g-cli.

Hi mononuclear,

This is exactly how this tool works only through C#. We just implement a couple of messages over TCP for stdout message and exit with code.

The limitations you see are because we send the port to connect to and the custom command line arguments over the command line into LabVIEW which means we must launch it.

• Custom Arguments: These could easily be changed to go over TCP.
• Port: This is the more complicated one. Because this is aimed to be general use we can't have a fixed port as in your example. What if the user already has that port in use? Or wants to run two applications at once (admittedly only in different LV versions in our case). We dynamically determine a free port and send it to LabVIEW to use. If we could find another way to transmit this port number then we could get around the launching restriction which is an interesting concept.

I will certainly make a note to look at other options for port discovery as it would be great to get away from the launching limitation but that is our restriction in trying to keep this multipurpose and easy to use.

That said there is nothing wrong with your approach for your application and provided you can handle port clashes then it may be a more suitable route for you.

from g-cli.

Created issue #30 as a placeholder for us to investigate whether we can remove the restriction on launching LabVIEW

from g-cli.

Just a suggestion:

Because you can start a LV program through application call and hand over some arguments .... (with the limitation that one cannot get a return code) .... why not make a LV call with a Port Number ... LV tries to call back via that port number if available within a certain time .... meanwhile the calling program waits for a certain amount of time for a connection attempt from LV (if successful it means the port is available) and if there is no call then send another application call with a changed Port Number .... till both programs talk to each other.

Well, I learnt a lot the last 24 hours about TCP communication .... and communication is established with fixed port nu.

from g-cli.

That is what happens at the minute but the application call only works IF LabVIEW isn't already open. If it is we can't all it again with additional parameters.

This is obviously not an issue with a built executable so that is a good way to avoid this issue if you don't need the LabVIEW IDE

from g-cli.