Create an API to Launch an LabVIEW Built Executable and Pass it Input Parameters

[blackburnite]

Hello,

I'm looking for a way to create an API to Launch/Close an executable, created with LabVIEW, which in additional to Launching/Closing tht executable, will also allow me to pass input parameters.

To give you some background, I'm working on a logging utility, basically a background dameon, which I currently have implemented as a LabVIEW packed library and my API is a few VIs to launch that daemon and pass it a filename and a logging rate.  Functionally it works just fine however is executes within LabVIEW not as an independent process.  So instead of using a packed library, I would like to compile my logging daemon down to an executable but I still need a way to launch it and pass it parameters from an external application (such as Teststand).

I know you can launch executables and pass parameters using windows command lines, but I'm wondering if there is a more direct method such as a DLL that I could call in Teststand?  Thanks.

[mikeporter]

VI Server will do the job. When creating your executable be sure you can handle the application instance close event. That is the event windows uses to stop applications during a restart or shutdown.

Mike...

[Dennis_Knutson]

So what is your problem in creating the dll with the app builder?

[blackburnite]

I've been looking at the VI server to do this so I may just need to spend some time figuring out how to implement it that way.

[blackburnite]

Creating an arbitrary DLL is easy enough, the question is the underlying functionality within that DLL.  

For instance, right now, I launch my daemon using the "Start Asynchronous Call" node, similarly to how the Actor Framework works if youv'e ever looked at the underlying code for that.  The problem is you obviously can't launch an executable using the same method so the question is how do I package that same functionality or similar functionaltiy into a DLL except for an executable, not a VI.

Another possibility I saw was executing a VI, packed library, etc in the runtime engine rather than in the labview development environment which would solve the problem I have.

[Dennis_Knutson]

So you're not using TestStand and running it in a sequence in a different thread?

[blackburnite]

No, the Logger is built using LabVIEW, teststand calls a "LaunchLogger" VI when a sequence is run and a "StopLogger" VI when the sequence completes.

The actual logger itself runs outside of teststand.

[Dennis_Knutson]

I don't see how you can say it runs outside of TestStand when it's launched by a sequence and why you can't launch it in a separate thread since that appears to be what you are asking about.

[blackburnite]

When Teststand Launches the Logger, it does so by opening a reference to the logger daemon using the "Open VI Reference" primitive and then it launches an instance of the dameon using the "Start Asynchronous Call" node.

This currently, launches the logger within labview not teststand.  If I were to directly call the logger daemon VI itself as a step in TestStand, then it could run in a new teststand thread.  At that point I would need a way to stop that logger which I should be able to do by storing a reference to its control queue within the teststand thread that it is running in.  Since teststand let's you specify VI execution in the runtime engine instead of LabVIEW that might do the job.

The one catch is once the sequence completes, the logger does some cleanup, post processing, etc that depending on the amount of data captured can take some time so if a set of sequences needs to be executed, this could hang up teststand until that post processing is completed.  That is one reason why I wanted it to execute outside of testtand so that additonal sequences could continue to run while the daemon finishes up in the background.

But, it's something I'll have to look into.