LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

force strict typedef

I am having a heck of a time getting a property node to take on a strict boolean typedef so its value property will be a boolean instead of a variant. I have a strictly defined refnum (for passing in a stop button from a higher VI) and if I hook it up, the property node is strictly defined. But I want the code to behave OK if the sub vi is running as the top level VI or if no external reference was provided. So, I have built in a couple of tests and substitute a reference for the front panel stop button if either of these cases are true (i.e. if there is no external reference or the VI is running as the top level VI) (see code snippet in attachment). So the reference is either to my strict refnum or to a front panel Stop button. However, when I hook this line up to the property node it converts to Bool (as opposed to Bool (Strict)) and the Value output becomes a variant, which I can no longer hook to an OR gate. I have used this approach a lot to pass references to waveform graphs in and never had an issue. How do I force this property node to be Bool (strict)?

 

You would think you could just left click the property node and force the strict cast. Too simple?

 

0 Kudos
Message 1 of 6
(3,340 Views)

Might be helpful to post the actual code. What is the specific error that it reports for the broken wire? What is the mechanical action for the referenced button?

0 Kudos
Message 2 of 6
(3,321 Views)

I'm not sure that I understand what you're trying to do exactly but if the mechanical action of your stop button is set to any of the 'latched' options, then this would prevent the value property from being strictly typed.

Which I guess makes sense - you cannot use a local variable to read a latched boolean, so it would make sense that you shouldn't use the value property to read a latched boolean.

0 Kudos
Message 3 of 6
(3,317 Views)

I think nathand is on the right track.  It looks like the mechanical action is set to latch.  You can only get/set booleans with a property node or local variable if the mechanical action is a switch type.


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 4 of 6
(3,315 Views)

This whole thing was driven by an example given under control references- overview, in which a stop button in a calling VI is used to stop a while loop in a sub vi.  My actual application had to do with stopping a triggered daqmx operation in a sub vi when you decide to abort the operation. Anyway, I found a copy of the vis involved (zone.ni.com/devzone/cda/epd/p/id/3769) and sure enough when you check the operation of the stop button in the main vi, it is set to switch while pressed (i.e. not latched). This isn't a great solution since it requires you to hold down the stop button for at least one loop interation. Interestingly enough there is no problem connecting a latched stop button to the stop control of a while loop if the stop control is on the front panel of the vi with the while loop. This is strictly an issue with passed control references and an extremely inconvenient one as what I wanted to do should be pretty common i.e. set up a daqmx operation (either triggered or continuous operation) in one vi, test it and then use the working vi in a higher level vi. In order to stop the acquisition process you need to pass a boolean to the stop control of a while loop in the sub vi.

 

After further experimentation, it appears, you can set the top level stop button to switch when pressed (or released). This is acceptable to the strict type def. The sub vi then has to manually reset the button to its off state. The only problem with this is that you have to set up the stop button on the sub vis control panel to operate in the same way (i.e. you can't use the more natural latched operation you would normally use)

 

The alternative approach would be to use a latched stop button in the upper vi and live with the non-strict boolean in the sub vi by somehow casting the variant output of the property node to boolean. A piece of cake in something like Measurement Studio, but I have no idea how to do it in Labview.

0 Kudos
Message 5 of 6
(3,284 Views)

rossu wrote: 

The alternative approach would be to use a latched stop button in the upper vi and live with the non-strict boolean in the sub vi by somehow casting the variant output of the property node to boolean. A piece of cake in something like Measurement Studio, but I have no idea how to do it in Labview.


I don't know about Measurement Studio, but here's why you wouldn't want to do this in LabVIEW: the value you would get from the control reference would depend on when the terminal was read, because that's what releases the latch. Personally I'd pass a notifier into the subVI instead of the control reference. If the notifier refnum is invalid then use the local boolean as the stop condition; otherwise check the notifier.

0 Kudos
Message 6 of 6
(3,259 Views)