Exchanging data between applications

[emcware]

 

Hello,

 

I recently discovered a new function in LabVIEW 2019 called ‘Get Command Line Arguments.vi’.     It allows an application build from LabVIEW to be launched and accept arguments from another application.    The arguments come in the form of a string array.

 

 

I was not aware of this but it is and has been possible for some time to do the same thing using the ‘Application:Command Line Arguments property node.

 

 

I often call applications to perform specific tasks from my main program.   It is reasonable to ask ‘why not simply embed the functionality’ directly into your main LabVIEW application?’   In my case, my main application is very large (1000s of sub-VI and yes, lots of OOP) and it take quite a bit of time to compile and build the application, which I distribute to a number of users.   I find in some cases it is easier to develop a separate application to perform a specific task and I may have a number of revisions during development and/or maintenance.    I often build applications from Python using pyinstaller and I call these from my LabVIEW application.  However, with Python I can include a simple print statement to generate output and my main LabVIEW application is able to read these print statements.   

  

Is there a method to pass parameters back to the main LabVIEW application after the small executable has finished, equivalent to how I use print statements in python?   

 

Here is link to 'Get Command Line Arguments.vi'

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000000YHdICAW&l=en-US

 

thanks,

 

 

[dadreamer]

4 hours ago, emcware said:

Is there a method to pass parameters back to the main LabVIEW application after the small executable has finished, equivalent to how I use print statements in python?   

I think, you need to organize some kind of Inter-Process Communication (IPC) between the two. As long as both apps are made in LabVIEW, you have a wide variety of ways for them to communicate: TCP/IP, UDP, Network Streams, SV, Pipes, Shared Memory etc. I don't recommend the files-based IPC because it has some negative caveats like these. There's also an article on the other side: Inter-Application Communication (rather dated though).

[Rolf Kalbermatter]

18 hours ago, emcware said:

Is there a method to pass parameters back to the main LabVIEW application after the small executable has finished, equivalent to how I use print statements in python? 

There is and it is called Interapplication Communication. Which one to use depends on the platform and your familiarity with a specific method. 

- File IO (multiplatform, trivial to setup, difficult to manage as you have to deal with concurrency of two applications trying to access the same file)

- DDE (Windows only, ultra ancient and much older than legacy, don't ever use it if you can help it)

- Shared memory (super high throughput, complicated to use, pretty different APIs and methods on each platform)

- (D)COM (Windows only, complicated to use from anything else than C(++).

- Pipes (Standard method on Unix, LabVIEW supports it on Unix platforms only, Windows has pipes too but it is a fairly obscure and seldom used feature)

- TCP/IP (multiplatform, native support in LabVIEW, almost as high throughput as Shared Memory when both sides are on the same machine since the network socket uses internally shared memory to transfer the data between the two endpoints, can also work over the network where client and server are on different machines)

- If both sides are LabVIEW based, you can also use the VI Server interface. That goes over TCP/IP too under the hood, but gives you a fairly easy method to directly access VIs in the other process.

The TCP/IP method is by far the standard method nowadays. It is ubiquitous on pretty much every platform, from the tiny embedded controller up to super duper ultra high performance computers. It has a few minor challenges such as proper network setup, the very distinctive server/client model and if you do not want to have to configure the client and server in some ways for their IP address and port number, you need additional complicated services that let you discover the according resources on the network. Most of them do however cause more trouble than they solve, so for your home grown kitchen sink automation, the easiest is to simply leave these things configurable in an ini file or something.

[ShaunR]

19 hours ago, emcware said:

However, with Python I can include a simple print statement to generate output

Generate output to a command prompt? LabVIEW has no concept of a being a console application and you can't natively create one. You can execute console apps using System Exec but if you want LabVIEW to behave as if it were a console app, you have to program a VI to specifically send to stdout and stderr streams.

There are a couple of solutions to this:

But my preferred solution is Rolf's Pipes API.

[dadreamer]

1 hour ago, ShaunR said:

But my preferred solution is Rolf's Pipes API.

There's also LV Process pipes implementation (part of GOLPI project), which seems to work in 64-bit LabVIEW and is more or less updated. Honestly I've never given it a serious try and I recall some limitations of it comparing to the Rolf's library (e.g., the lack of stderr support AFAICR).

[ShaunR]

2 hours ago, dadreamer said:

There's also LV Process pipes implementation (part of GOLPI project), which seems to work in 64-bit LabVIEW and is more or less updated. Honestly I've never given it a serious try and I recall some limitations of it comparing to the Rolf's library (e.g., the lack of stderr support AFAICR).

I've been badgering Rolf for years to release his API properly. He's produced some fantastic API's that have no equal in terms of function and quality-especially cross platform.

My current use case is for ffmpeg.

Edited June 4, 2021 by ShaunR

[emcware]

Thanks everyone for the great suggestions.  I can't wait to try these.