Reentrant Help!

[Valcon]

Hi all! I hope everyone is well today,

Just to start off, I'm running Labview 8.2 on XP. Because of my company's concerns I have added images of a simplified version of the vi that represents san example of what I'm trying to do. That being said, here's my dilemma:

I am trying to call a subvi more than once simultaneously in my main vi. The only variable that will be shared is a single array, and it will only be read from, not written to, so there shouldn't be any data handling errors. The subvi that is to be called is set up as a reentrant, and the help file indicates that this is the proper method of handling this kind of repeated calling and simultaneous usage of a subvi. However, when I try to call the subvi a second time before the first call has finished executing, the second call will not execute until the first has finished. The help file indicated that this is what would happen if a subvi was called when it was NOT a reentrant. Can someone please help me trouble shoot this problem? I can't figure out if it is an incosistency in Labview or if I'm overlooking something! If this is not the proper method of calling a subvi more that once simultaneously, I'm more than willing to change my operations. Thanks,

Ryan

PS: To clarify, Reenrant.jpg is the "mainvi" here, and is the example of what I'm trying to do. Reentrant.jpg is the "subvi" that I'm trying to make simultaneous calls to.

[Graziano]

Hi!

   Reentrancy of top-level vi shouldn't matter...

   I've found this and this, hope it can help.... please, let me know!

   I confess that sometimes I get in troubles with reentrancy, because also the correct definition of this concept is sometimes confusing: to someone, non-reentrant means ONE instance, and it'd be not the case!

   Have a nice day!

graziano

[Graziano]

M..... not sure I understood, sorry!

   In Reentrant.JPG you have the Main Vi, in which "Multi Execute module" is callet twice, and you wish to have two simultaneous and safe calls... the Variables in "Multi execute module" are local, i guess... if so it should work....

   More, how do you know that the second call does not execute until the first has finished?

   Please, report if you find the problem!

graziano

PS.:it seems that there're differences in configuration options of vi property-reentrancy between LV 7.1 (that I work with) and LV 8.2.

[Valcon]

Thanks for the speedy response!
I have still found that I can not get the two Vis to execute simultaneously! I have also tried not opening the front panels, however I think I may have found the problem...
In the Multi-Execute-Module, I have a subvi that checks the serial port. When the Visa resource is tied up, I do not believe that any other object can access it, reentrant or not. There fore, I am trying to have the serial read done in the main Vi and parse the results into a global indicator. Still, because the serial read and the write to the global is in the main vi, I cannot pass the values along with out coming out of the subvi, to allow the serial port to be checked... I'm still not sure what to do about this problem! The advice and information was good though, and I do appreciate it.
Ryan

[billings11]

Valcon,

Even if you label a vi re-entrant it will still follow all the flow control rules of labview.  So it will still wait for the error cluster, etc. to be passed out of the vi before moving on in the program.  In the context of your program there it won't change anything to make it reentrant, since your while loop is going to wait for all of its contents to execute before moving on to the next iteration.

They way I like to handle this is instead of calling the reentrant vi in the normal way, call it by vi server.    Instead of plopping your subvi on the diagram like normal, open a vi reference to the vi and choose the run vi method.  Then instead of waiting for your vi to finish executing before moving on, it will launch the vi in a seperate thread and move on without waiting for it to finish executing. 

[billings11]

Try it like this:

Here I'm setting some control values and calling N number of "ABTSTestSequenceEngine.vi", all executing simultaneously and on their own thread.