LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

front panel input data on dynamically launched reentrant vis- why doesnt it populate?

Solved!
Go to solution

I'm wondering why dynamically launching reentrant vi's for viewing some front panel data input data wont work...

 

I notice that the front panel does work for data that is generated by that specific instance, but the inputs to that vi dont show up.  Would love to know why...  I see it's mentioned in some other posts like this one:

 

https://forums.ni.com/t5/LabVIEW/How-to-monitor-front-panels-of-reentrant-VI-s-during-development/m-...

 

 

thanks in advance

 

edit: interestingly enough... if I take a string passed into it from the calling vi and try to appends something and display it... that doesnt work either 🤔

 

0 Kudos
Message 1 of 11
(1,718 Views)

Well, if you want help, attach some simple code where we can reproduce your problem. Make sure all controls contain typical default data. Explain exactly what you are doing, what you see, and what you expect to see instead.

 

(Linking to an 8 year old thread does not help.)

0 Kudos
Message 2 of 11
(1,675 Views)

touche- apologies for my poor assumptions.

 

attaching a caller vi and a callee vi i just whipped up only to show the behavior I'm referring to.

 

I saved as LV12 but am on 2018 (64b).

 

The control doesnt show the data, but the indicators do, I'm just curious as to why since I always seem to forget this when expecting to see data useful for debugging...

 

thanks

 

 

 

 

 

 

 

Download All
0 Kudos
Message 3 of 11
(1,668 Views)
Solution
Accepted by topic author p27

This happens because the controls are updated before the front panel is loaded.  You need to open the VI reference, open the front panel, and then call it.  You will want to move your Open VI Reference to be inside of the FOR loop and use options 0x80.

 

VIs are saved in 2016.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Download All
Message 4 of 11
(1,648 Views)

I thought I wound up using option 40 for timing reasons (likely an unrelated issue caused it but I was having a weird delay when running the async call).  I went to test that with this example and I cant tell the difference, it runs just as fast in terms of the front panels coming up.

 

thanks again - i will try this on my next app where I'm launching multiple processes for various tasks

0 Kudos
Message 5 of 11
(1,630 Views)

I have actually ran into this enough that I created a malleable VI specifically for opening the reference and optionally opening the front panel.  The Asynchronous Call By Reference should be called after this vim.  Example below.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Download All
0 Kudos
Message 6 of 11
(1,621 Views)

oh this looks handy, though I have no experience with vim's - this may be my first attempt to use one...  I see two errors related to the inlining, which if i disable it says it's required for malleable vis...

 

p27_0-1622574888347.png

 

what am I missing here? 

 

thanks again

0 Kudos
Message 7 of 11
(1,614 Views)

You probably need to right-click on your VI Reference and select "Strictly Typed VI Reference".  You will notice a start on your icon then.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 8 of 11
(1,596 Views)

the vim is broken when I open it... wiring a strict ref doesnt change anything when I drop it in another vi 🤔

 

 

 

0 Kudos
Message 9 of 11
(1,536 Views)

@p27 wrote:

the vim is broken when I open it... wiring a strict ref doesnt change anything when I drop it in another vi 🤔


It is not broken for me. What is your exact LabVIEW version? What is your OS?

0 Kudos
Message 10 of 11
(1,530 Views)