best practices with "shared clone reentrant execution"

[mysticfree]

I'm writing code for a tester that has 4 duplicate fixtures, each one independent from the others.  I'm thinking that I can use a main vi for tracking of the results of each fixture test and would call 4 instances of the fixture test program.  If I set the fixture test program to "shared clone reentrant execution", would I need to set "shared clone reentrant execution" for all of the sub-vis in that fixture test program?

Thank you!

[Bob_Schor]

There are two situations where I have use "Re-entrant Execution".  One is the situation you describe -- I want to have multiple (parallel) instances of a processing routine running simultaneously.  The other is when I want a recursive routine -- "List all of the Files in this Folder and all of its sub-Folders" -- which you code by making the routine call itself (if you think about the "List all Files" problem, you can solve it by listing all of the files in the folder, then pass each Folder to "List all Files" to list all of the files in the folder, which calls "List all Files" to list all the files in its sub-folders, etc.)

Recursion I usually use Shared Reentrancy, as I don't need VI to be called multiple times.  When I've used parallel instances, I've almost always used Pre-allocated Reentrancy.

But what about your question, namely about the VIs that these Reentrant VIs call?  The answer is "It depends".  If the sub-VI is not reentrant, then all four parallel Instances may try to call the single copy simultaneously.  If it does something "fast" (I can't think of a good example right off-hand), then it probably won't make much difference, and will be one less thing to worry about.  Perhaps more important, does the sub-VI need to "remember" anything about the VI that called it, such as storing anything in a Shift Register?  Then you definitely want a Pre-Allocated clone, so Clone A always calls sub-Clone A, saving A's stuff in sub-Clone A's Shift Register.

I just looked at one of my older "Clone" Projects (I went crazy -- each Clone, up to 24 of them, had three parallel routines, so we could have 96 clones running simultaneously).  Most of the sub-VIs at the top level of each Clone were also re-entrant.  The exceptions were routines which did simple computations once (like computing the number of buffers I needed, takes little time and is done once/clone) and routines that (quickly) returned a program-updated Global Value (like how many milliseconds had the program been running).

If you want further recommendations, post the relevant code (no pictures, please -- a .zip file representing the compressed folder containing the entire Project is best) so we can better understand your situation.

Bob Schor

[mysticfree]

This is excellent, Bob.  Your explanation gives me a better idea of what I have available.

Since I'm in the planning stage, I don't have working code yet.  I do have a visual representation of the layout as a sanity check. But you did request no pictures.  So, as I begin coding, I'll put together a package for review as soon as I can.

Thanks,

Ron

[mysticfree]

ok, Bob, I've uploaded a crude example in a zip file.  As I wrote this quick VI, it made me wonder how does LabVIEW know to create just 2 clones - 1 for each loop - and not 4 clones since I call the "water tank" vi 4 times?

[JensG69]

Short answer: LabVIEW will not know and call four (independent) clones.

Regards, Jens

[mysticfree]

How well does NI Digital output (NI-9476) handle simultaneous calls to different bit positions?  It seems like I had issues with this 10 years ago and gave up on using reentrant clones.

[Kevin_Price]

DAQmx is multi-threaded and supports simultaneous calls.  That said, you still need to avoid contention for hardware resources and I don't personally have familiarity with the 9476.

It likely allows you to have separate software-timed tasks for each individual digital line you want to read or control.

If it might have been more like 15+ years ago that you had trouble, you may have tried this scheme out under the legacy driver, a.k.a. traditional NI-DAQ.  It was NOT multi-threaded, and any use of driver calls to the hardware would block other attempts to make driver calls in parallel.

-Kevin P

[Sebastian.Weber]

---

@mysticfree wrote:

ok, Bob, I've uploaded a crude example in a zip file.  As I wrote this quick VI, it made me wonder how does LabVIEW know to create just 2 clones - 1 for each loop - and not 4 clones since I call the "water tank" vi 4 times?

---

That's how shared reentrant VIs work. When LV calls a shared reentrant VI, it first checks if there is a free clone it can re-use. If not, it creates a new clone, and uses that one. Clones are created during runtime, which costs some time. But by re-using old clones, this saves memory.

In your code, one loop calls the SubVI a second time after the first call has finished. That is, the SubVI will run not more than twice in parallel, and so, LV creates two clones.

For pre-allocated reentrant VIs, LV will check at how many locations the VI is called, and create a clone for each. This is done before running, costs memory, but is faster at run time.  

In your case, there would be four clones for the SubVI, since there are four locations where it's called.