Is it possible to pass arguments to a VI using 'Open VI Reference'

[MrQuestion]

I am modifying pre-existing code. (I state this, because there numerous other ways to work around this, but I'm stuck with what I have)

I have a large project that is compiled into an EXE.

Inside this project it uses the "Open VI Reference" to VI's that are packaged within the compiled exe.

All good, right?

Well here is the question,

Is it possible to include command line type arguments with a "Open VI Reference"?

Where i can say "Something.vi /Option:Foo"

I have tried many variants such as

"Something.vi -- /Option:Foo"

even tried variants such as

"C:\MyLVProgram.exe\Something.vi /Option:Foo"

(interestingly enough there is no error when you do "C:\MyLVProgram.exe\Something.vi" when running the Open VI Reference.)

This exe will be deployed to a system that has only the runtime engine installed.

My current environment is LV 8.6.1. (I know, it's old)

It appears that the LabVIEW primitive only recognizes paths, and in all other cases I get an error 

Error 1026 occurred at Invoke Node in Something.vi->MakeSomething.vi

Possible reason(s):

LabVIEW: VI Reference is invalid.

Any ideas?

[crossrulz · Accepted solution]

You can only send command line arguments to an executable with the System Exec.  If you want to pass data into the VI, then use the Run Asynchonous Call.

[jimchretz]

How were you expecting to handle those arguments in Something.vi? Even as EXE you still need a property node "App.Args" to get the arguments received from Windows.

You need to modify that VI somehow, right?

You can just add a control in that VI, can be a String for instance Labelled "String". And use an invoke node to pass your command.

 

[MrQuestion]

Your solution is one of the approaches that I mentioned.

Yes that would work, but I'm modifying some very old code in a very large infrastructure.

The design pattern of this code most 'closely' represents a factory pattern.

I can create new VI's and launch them from the factory, but I can't really change how the factory launches the VI's without changing all other VI's to accept the same interface. (that would be thousands of VI's)

And, in case you were wondering, OOP was not used. So, there is no quick fix with changing the class model.

I created a new VI, and I was really hoping to add in a simple way to pass a few configuration parameters into my VI while still being backward compatible with the existing infrastructure.

And, yes I was using App.Args in my new VI.

I know that LabVIEW has some quirky little tricks hidden in some weird places. I was hoping that passing arguments like this would have been one of them. 

Thank you to everybody for looking into this!

[Bob_Schor]

If you are using Old Code in "New" LabVIEW (and not that new at that), you can use Start Asynchronous Call, which does provide inputs for controls.

Bob Schor

[mikeporter]

The technique that Jim gave will.let you pass values to the control's front panel. But there are a couple nuances to consider. First, it the VI that you are accessing already executing. If so you need to consider when the cidecreads its front panel. If the original code onlyvreads its front panel when it starts, changing the control value won't do anything useful.

If the VI is not currently running then you can dynamically run the VI one any of 2 or 3 techniques. Bob mentioned one that I like. However, if you run a VI using VI Server that can block the remote program from running it, which can cause some unfortunate side-effects

Mike...

[MrQuestion]

I need to clarify that this is part of a much more massive infrastructure.

I know that it would be easier to just show you the code that I'm working with, but the company has very tight policies.

I can only add or remove VI's to our existing infrastructure. 

Below is an example of the design pattern being used.

I can not change the items in red; only the string that has the array of vi's.

I work in a regulatory industry, so anytime I touch a VI I must go through an extensive review process. I really don't want to do that.

I do have other options available such as environmental variables or external files such as ini, but that would be very inconvenient.

I need to manage hundreds of these deployments, and the prospect of managing another bit of data in a special location only adds to the cost of data management.

Not every deployment will be using this VI, and not every application of this VI will have the same configuration. 

I may be beating myself up over this. 

I usually don't double support, but I might open up a ticket with NI and confirm what everybody is already telling me.

This is to sweet of a opportunity for me to maintain backward compatibility while supporting new VI's.

I have verified that the logic preceding the open vi reference is not affected by the arguments, and the entire string is feed into the open vi reference primitive.

Once again, thanks!

[jimchretz]

If you can't change the items in red, how did you figure how they would handle your parameters?

The VI that receives your Strings, even if you can't change the code, you have access to its code, right?

Without changing it you can open a reference to it and set some control values from your VI.

[MrQuestion]

I do have access to the code, but I can not change the code. I work with dozens of other developers and the prospect of modifying our happy agreement on the factory model and how VI's are launched will raise chaos. 

My VI works as a daemon, and there are no front panel elements. 

The parameters are communcation settings.

In any case this thread is getting away from the topic. 

I was only looking for a way to cheat the open VI reference into passing additional arguments.

Thanks!

[Yamaeda]

Use the string with arguments as you wish to do, but add a "filter out arguments" which stores it in an Action Engine. The VI server calls are then unaffected and your new VI can use the Action Engine as "input" parameters. How's that?

/Y