Cannot pass argument to dynamic re-entrant VI

[RayR]

I've worked with dynamic events for many years; however, this is the first time I implement code that calls a dynamic re-entrant VI.  The VI call works and the dynamic VIs run.  That's not the issue. 

The issue is that we wire values to the dynamic VI call.  When setting the VI as normal (non-re-entrant), the values make it to the dynamic VI without any problem.  However, as soon as we turn on the re-entrant features, the values are no longer making it to the dynamic clones.   I am curious if anyone has seen this in prior projects?  Is it a bug?  Is it a limitation?

The reason for this approach is that we need to make a call to a function that measures sound pressure levels using a microphone attached to a DAQmx card.  The number of microphones can vary from 1 to 2 to 4 to 8 to 16 (and possibly some combinations in between).  Using a re-entrant VI was the natural was to implement this.  However, the function (VI) needs to run dynamically and wait for a rendez-vous signal while other processes are running in parallel.  All of the measurement and noise sources need to run in parallel; hence, the use of dynamic VIs.

In the code shown above, you would expect the value 30 to appear in the dynamic VIs.  That is the case when re-entrant is turned off.  We tried both combinations of re-entrant configurations, various configurations for the opening of the dynamic VI (as can be witnessed by the hex constants on the block diagram).  Some of the code such as looking at the number of iterations is for debugging purposes. 

Any comments?  Or ideas?  Is it a bug?  Or a limitation?

I do have a workaround in mind, but would like to know why this issue surfaced in the first place.

Thanks,

RayR

 

[ensegre]

1 hour ago, RayR said:

the values are no longer making it to the dynamic clones

just to exclude the obvious: how do you know? Are you inspecting the right instance of the clone?

[smithd]

I've never seen this issue myself. To simplify debugging, maybe just put in a 1-button dialog tied to the value (30) and make sure it pops up as you expect.

Also, the open vi reference inside the loop concerns me. The point of x40-80 is to create a clone pool which can be executed in parallel. You're executing N clone pools but only using 1 clone from each pool. 

[RayR]

To answer the first question:  the default value for duration is zero 0.  When calling the VI, it passes a value of 30.  When setup as a re-entrant VI,, none of the clones show any value other than 0.  When setting the VI as non-re-entrant, the value of 30 appears in the control of the VI.  We also have breakpoints in the dynamic VI and monitor the values.

The second question:  We have probed both the calling VI and the dynamic VI.  Simply changing it to non-re-entrant results in getting the value 30 as expected.  Opening the VI reference inside the loop was a recent modification during the investigation.  You may be giving me an idea.  Something that I have never tried...  Are you saying that setting the x40-80 will create a clone pool even if the VI is not set as re-entrant?   Because your last sentence appears to be correct.  We have another parallel VI which has the earlier implementation where the Open VI Reference is outside the loop.  They both share the same  / similar issue.  While waiting for your response, we will investigate.

 

[ensegre]

Could you trim that down to some code without hardware dependence, which we can look at?

Oh, and you mentioned dynamic events. Are they involved here, so that you have reasons to blame them?

Edited January 24, 2017 by ensegre

[RayR]

No dynamic event...  Just Dynamic VIs. 

I tried variations on what you wrote and none of it worked.  As a matter of fact, I discovered more... let's say "troubling" features..  concerning Dynamically calling a re-entrant VI.  I would be extremely surprised if I was the first to attempt such an approach.

For now, we implemented a workaround.  As I have time, I will create a snippet of similar code to investigate.

[smithd]

5 hours ago, RayR said:

Are you saying that setting the x40-80 will create a clone pool even if the VI is not set as re-entrant?

Not if its non-reentrant, that will throw an error, but you can I believe specifically allocate 1 instance, inside a loop, by opening a new reference with 0x80. I believe I've seen other people do that (and I've always been surprised it works).

Personally, I always do exactly 1 pattern:

-Use static strict VI ref to get VI Name
-Wire static strict VI ref + VI name to Open VI ref once and only once ever during the execution of the entire program. Use 0xC0 (40,80).
-Call start async call as needed. 

I've never had an issue with this pattern.

The reason I suggested the 1-button dialog as an additional check is because I've seen situations where the debug information doesn't get set in a reentrant function -- for example I definitely wouldn't look at the front panel, as I believe I've seen the front panel show the default value in some situations. I've also mis-placed breakpoints to properly debug, so putting in the dialog is a quick way to be doubly sure.

Long story short, its definitely not a limitation of the feature, but I have no clue why you're seeing the behavior you're seeing.

[ShaunR]

I cannot replicate your problem. (Untitled 1 Folder.zip)

Edited January 24, 2017 by ShaunR

[drjdpowell]

How are you opening the Front Panels of your clones?  If you’re trying to use those references opened with 0x40, you will be opening a different clone that the one you started (someone on NI.com had this problem once).

[drjdpowell]

Also, make sure your FP is loaded before your indicator is written.  Your input Controls will show default values if the subVI was run before its FP was loaded, even though the proper values were passed.

[RayR]

We're doing something very similar to what you did in your demo code (thank you).  Your demo worked on my machine.. I will try it on the other development machine where the "bug" was found.

Dr. Powell:  While debugging, we are opening the Front Panels.  How?  Well... they opened automatically as set in the VI properties (to open when called).  We also used an invoke node to open the front panel.  It did not change anything.  I will pay attention to your last recommendation.  Thanks

[Neil Pate]

4 hours ago, smithd said:

Personally, I always do exactly 1 pattern:

-Use static strict VI ref to get VI Name
-Wire static strict VI ref + VI name to Open VI ref once and only once ever during the execution of the entire program. Use 0xC0 (40,80).
-Call start async call as needed. 

I've never had an issue with this pattern.

This is exactly the same method I use. I use it to dynamically launch single instance of VIs that are never expected to be re-entrant, and also re-entrant clones. The only difference for the re-entrant clones is the flags used to open and the VI itself needs to be set to re-entrant.

The two flags in the VI below are just the 0x80 and 0x40 flags.

 

Edited January 25, 2017 by Neil Pate

[drjdpowell]

Dr. Powell:  While debugging, we are opening the Front Panels.  How?  Well... they opened automatically as set in the VI properties (to open when called).  We also used an invoke node to open the front panel.  It did not change anything.

If you’re using “Open when Called” then the FP will be loaded before anything else happens, so that can’t be the source of your problem.  Be wary of using an invoke node on the VI block diagram, as the FP doesn’t exist until after that node executes.

[drjdpowell]

Note:  0x40 isn’t to open a ref to a re-entrant VI; it’s to open a common reference to a pool of shared clones.  If you just want a single clone then don’t use 0x40.

[Neil Pate]

Thanks James, I have probably just labelled my code poorly, when I set the "Re-entrant" flag to true it is because I want multiple clones.