dynamically loading VIs from an application

[PA-Paul]

Hi all,

Quick (hopefully!) question.

I have a "top level application" which will be built into an exe and I want to be able to call small "utilities" from within it. The utilities should be able to remain open without preventing the top level app from accepting user input. The utilities should be separate and modular, but they need to be able to send instructions back to the top level app. They may also need to take some information from the top level app at the point they are called.

My main app has a queue structure, so as long as the utilities can access the queue sending instructions is fine. What I've done for the moment is to build the "utility" into an llb, and then load the top level vi dynamically. I used the "call by reference" function to open the VI and that all works, except that it blocks - i.e. it wont return control to the top level app until the utility is closed. I used the call by reference so I could wire in an input to the utility - so I can't use the "run" invoke method and tell it not to block...

Is there any way to use the call by reference function without it blocking?

this is all in LV 8.6 by the way...

Cheers

Paul

[crelf]

I used the call by reference so I could wire in an input to the utility - so I can't use the "run" invoke method and tell it not to block...

You can call the VI dynamically using a loosely-typed invoke and then set the inputs on the FP, then use the run method in non-blockling mode...

[Yair]

Is there any way to use the call by reference function without it blocking?

No. Please go and vote for this idea (and tell others to) so that we will have this feature sometime:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Adding-a-quot-don-t-wait-until-done-quot-option-to-the-Call-By/idi-p/917632

[Jon Kokott]

No. Please go and vote for this idea (and tell others to) so that we will have this feature sometime:

http://forums.ni.com...By/idi-p/917632

A workaround I have used in order to achieve this functionality is to use a Daemon launcher to enact the static VI call.

Do this by creating a launcher with two cases

1. A case where the vi opens a copy of itself and populates all the control values and then runs. (I typically open the daemon process here as well, and pass it to the new instance and out of the current instance so that you have the reference handy)

2. a case where the vi detects that it is the clone and performs the call by reference node.

In case 2 the VI doesn't have to be a call by reference node. It could be a standard VI call. A call by reference (with a strictly typed static VI reference somewhere in the call chain) will guarantee that the the process is reserved and your abort button will abort this process.

[PA-Paul]

Hi crelf,

Any chance of a quick screenshot of how to do that?

Thanks

PAul

[Mark Smith]

Hi crelf,

Any chance of a quick screenshot of how to do that?

Thanks

PAul

How about this?

Use the Control Value Set method to pass data to the controls and then run the VI with the wait until done flag set to false. It's particularly easy with classes because all of the current values of the class data get passed with one call the the Set method.

Mark

[PA-Paul]

Thanks!

Got that working great. Not into classes I'm afraid. I feel I ought to be, but just don't have time to go down that route (I'm a physicist by trade and training, so I do my best to write good "g" but I've never got into oop (well - "oops" I can do!))

Thanks again.

Paul

[Rob Calhoun]

No. Please go and vote for this idea (and tell others to) so that we will have this feature sometime:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Adding-a-quot-don-t-wait-until-done-quot-option-to-the-Call-By/idi-p/917632

Like Mark said, just set "Wait Until Done" = F and "Auto Dispose Ref" = T. But it's sort of a pain to get all of the details right with passing arguments. Jason Dunham and I wrote a library that handles most of the nitty-gritty of spawning off a new process, including passing arbitrary arguments via a queue that shares the clone name and taking care of the handshaking. We think this is a better (albeit more complicated) approach than setting control front panels because sometimes you want the caller to be blocked until the spawned process completes some specific action.

Our plan was to clean it up for release it through OpenG, but there never seem to be enough hours in the day. (How does Jim K. squeeze 56 hours into his day?!?)

Here is a screenshot of a fairly complete example as a teaser:

[crelf]

Use the Control Value Set method to pass data to the controls and then run the VI with the wait until done flag set to false.

Right - that what I was trying to get at. Thanks for posting the screenshot.