Jump to content

Cannot pass argument to dynamic re-entrant VI


Recommended Posts

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.

dynamicReEntrantVI.png

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

 

Link to comment

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. 

Link to comment

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.

 

Link to comment

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.

Link to comment
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.

  • Like 1
Link to comment

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.

similar.png

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

Link to comment
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.

 

Capture.JPG

Capture2.JPG

Edited by Neil Pate
Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.