Running VIs in parallel

[jcurl]

Qutie a few posts indicate using the "Open VI Reference" and then with Invoke node use "Run VI" and set "Wait Until Done" to False to have it run in the background. But I see there's always the question of knowing where the VIs are.

I've seen in LV8.6 (don't know about earlier versions) the "Static VI Reference" which I used instead and I get the results I intend, until I want to run more than one instance of the VI in parallel. In this case, the second instance returns an error "1198: LabVIEW: (Hex 0x4AE) The VI is not in a state compatible with this operation. Change the execution mode of the referenced VI to reentrant for this operation".

I'm reading the LV help and see "You cannot use this method to run a VI that is already reserved for execution by another VI." which I don't really understand just yet. But I guess this is the salient point.

If I can't use a static reference, I've got it working using "Open VI Reference" and of course the issue here is having to provide the VI as the path, that works during development but doesn't when I run the EXE. Is it enough to always include the SubVI that is being run in the background as "Always Included" as part of the EXE generation from the project? Or are there other gotcha's?

Thanks.

Jason.

[Ray.R]

Can you skip all the details and simply explain what it is that you are trying to do?

What do you want?

Do you want :

1)  to run different vi's in parallel?

2)  to run the same vi in parallel?

I suspect it is #2, but I'm horrible at guessing games.. 

Without writing a chapter, can you say what you are trying to achieve? 

If it is # 2, then you need to make that VI re-entrant.  But I don't know if that is what you are looking for..

[jcurl]

I need to run the same VI in parallel, so #2.

Using "static vi reference" doesn't work (error 1198), but "open vi reference" does work. The VI is made reentrant and I've tried both reentrant models. Why the error in the first case? Is it even possible to get "static vi reference" to work?

If not and I need to use "open vi reference", what issues can I expect to have (because vi paths need to be provided) when building an application exe and how to avoid this?

[Ray.R]

You have not answered my first question 😉

Without saying what you did, can you tell us what you are trying to accomplish?  why do you want to open the vi using "open vi reference"?

Are you trying to create a dynamic VI (daemon)? <-- unlikely, because you normally wouldn't run multiples of the vi in parallel

or a subroutine (thus having cloned instances of the vi)? <-- sounds like this one...  because you want to run more than one instance of the vi in parallel

I'm just trying to understand the reason you want to use a static vi reference when you appear to want to call it dynamically...  Or maybe I misread something..  

R

[Ben]

A couple of notes to make this work.

1) The VI you are trying to clone should be marked as re-entrant (VI Properties >>> Execution)

2) Use the "8" option when opening a ref to the clone.

THis image is a code snippet that I use to create my clone instances (1-100 depending on how the app is used.)

 

I hope this helps,

Ben

Message Edited by Ben on 09-18-2008 07:46 AM

[jcurl]

My apologies. This is somewhat a theoretical question with regards to parallel VIs using the "Run VI" method. I don't know what's the difference between static and dynamic VI references and am curious about the differences I've observed. The only reason I would like to use static is because I can double click on it and specify the VI to take a reference of without providing a filepath that might change, but I don't think this is the reason why NI invented the two.

The actual VI is controlling a climate chamber over a period of 20min-1hour and needs to run in the background. It may be called a second time before the first VI is finished.

I understand there are many ways to do this and one could be to use notifiers as well so I would never need to have two instances of the same VI running in parallel. But as I said, I'm still exploring LV (it's about 3 months new to me, although C is my previous language for 15 years). I think this is my first problem.

My current implementation is to keep the VI that controls the chamber as a single VI that does all checks inside and a wrapper VI that then uses the "Run VI" method, using a notifier only to abort the VI. In this case, the same VI would run in parallel and the second instance would automatically detect it is already running. This suits well if the programmer of my drivers happen to use the original VI (not the wrapper) and uses forked wires.

[Ben]

THe difference between static and dynamic is implied by the names.

The static flavor will only allow a single VI as the target.

Dynamics let you determine at run time what VI to target. An example of using dynamics would be if you have a widget that you can control using two different types of hardware. One verion of the driver can be implemented for each type of hardware interface. The advantage of this approach is that you only need to install the drivers required for the hardware that will be used on that machine. THe OTHER versions are never opened so the lack of the appropriate support resourse do not complicate our lives.

Ben

[jcurl]

Thanks Ben. I do like your example and have used the Static VI to get the name and passed this to open a dynamic VI. I believe this would also overcome the problem of unexpectedly not finding a VI that would be caught at design/compile time instead of runtime when it could be too late.