LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Using VI Server in a subVI.

Solved!
Go to solution

I have a problem using "This VI" reference in a subVI. Attached are two VIs. My Logger Test1.vi is the calling LogVIControls.vi as the subVI. I am trying to get the control values and names in the subVI, and log them to an XML file. The problem that I am experiencing is the on the first run. The subVI reads the control labels correctly. However the value that is returned for each of these is control default value. If you were to hit the run button again, you will get the correct values logged to the xml file. I set the "Voltage In" control default to be 12. This allows you to see it is reading default values of the controls instead of the empty values.  Once in memory, you will always get the correct values. To repeat the error, you need delete the xml file, close LabVIEW. Then you can reopen and run My Test LoggerTest1.vi (and not opening the subVI). If you step through the VI, you will always get the correct values. If you probe and run, you will get the correct values, due to the subVI being open and in memory. It seems to only do the error when the subVI is not in memory yet. Any subsequent runs after this are the expected results. I have performed this test on many different PCs, and Different versions of LabVIEW (2014, and 2021), and the results are consistent. I am hoping this is something simple that I am missing. Thanks for your help.

 

@Darren, I will concede you are better than me a Set if you can answer this 😉

Download All
0 Kudos
Message 1 of 8
(2,039 Views)

Not that I have an answer as of yet, but will you either post an image of each of the block diagrams or post in an older version of LabVIEW please?

0 Kudos
Message 2 of 8
(1,985 Views)

Why would LV sacrifice performance by updating front panel controls on a closed VI? That's probably what's happening.

Add a This VI to the sub-vi and it'll force it into memory (though there's probably better ways to achieve your goal)

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 3 of 8
(1,936 Views)

It works correctly when I try it.

As a side note, you don't need "This VI" for a property node.  When the reference in to a VI property node is unwired, it uses the owning VI.

paul_cardinale_0-1666353365148.png

Similarly, when the class is "Application", it assumes the current application.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 4 of 8
(1,922 Views)

Here are the screen shots of the VIs.

My Logger Test1.png

LogVIControls.png

  

I can consistently get the different values on the first read. Could it possibly have something not installed (like a driver) that would cause this behavior?

0 Kudos
Message 5 of 8
(1,876 Views)

For optimization purposes, LabVIEW does not keep track of data values on controls and indicators until LabVIEW determines you want them, that is, until you read the value property or display the front panel. When you display the front panel, LabVIEW begins keeping track of the values.

The first time you read this on a VI whose front panel is not open, this method returns the default value of the control rather than the actual values. Thereafter, it returns the actual value.

 

So if you set the panel to appear first, either by operating on the VI reference or by changing the VI properties to show the panel when it runs, it should work the first time.

 

This is a pretty weird way of doing things though... Is this a proof of concept for being able to log the state of a VI when it's about to run, or something?  Like a universal debugging tool?

Message 6 of 8
(1,844 Views)
Solution
Accepted by topic author alright_meow

This seems to result in the desired behavior:

My Logger Test edit.png

 

That particular property node will force the subVI's front panel into memory at the right time.  Make sure to wire that panel reference somewhere as it seems that LabVIEW will just discard the operation if it sees that it is unused.  You can also put a first call case around that static VI reference and property node and it will still result in the desired behavior.  There are other property node and invoke node operations that will force the subVI front panel into memory, just take a look at context help when hovering over the node operation text.

 

One other thing to note: if this code finds its way into an executable, ensure that the subVI's front panel is not automatically removed during the build process by setting the proper build specification properties.  You may not run into issues with the static VI reference + front panel-specific property node present on the block diagram, but I didn't try it.

Message 7 of 8
(1,828 Views)

Awesome! That worked. Figured out I just needed a control property node on the block diagram, not necessarily the static VI reference. Thank You!

Message 8 of 8
(1,751 Views)