Latched Booleans and Vallue Signaling

[Pablop]

I used Latched Booleans (Latch When Released) with Events structures. Placing the boolean in the Event resets the boolean.

However, I also like to use the property node Value(signaling) so that I cn have other things trigger the event appropriately. However, for latched booleans the data type is variant (why?) and it doesn't seem to function correctly.

It looks like hat I need to do is use latch when pressed, then set the value to false (with a property node) in the event.

Is there something I'm missing? Why won't the variant data type value signaling work?

[smercurio_fc]

This is documented in the LabVIEW Help on the page for the Value (Signaling) property:

If this is a Boolean value configured with a latching mechanical action, this property always returns an error. Due to race conditions that can occur when you have a Boolean value with latching mechanical action, you cannot programmatically read Boolean values that are set with a latching mechanical action.

It is also documented here: Why is My Boolean Value Property Node a Variant?

[buckidge]

You may be able to accomplish what you need using an Invoke Method on the VI using Set Value on the control you're working with...

[smercurio_fc]

That would allow you to change the value, but unfortunately it doesn't trigger the "value changed" signaling event. Good idea, though.

[JÞB]

It is not really intuitive but if you think it through a latching boolean actually has 4 states.

True

False

True - False (The Control showing False but it has not yet been read)

False - True (The Control showing True but it has not yet been read)

Without the extra two possible states data flow would run into the same problem devised by Schroedinger where he could only conclude the cat was both alive and dead at the same time until the box was opened.  So the value in the UI thread (shown on the Front panel) is stored with a flag that does not get set until the value is placed on a wire. 

[Luis_AM3C]

Hi,

          EUREKA!!!! Its posible, only need use a type cast to a normal boolean.

           Here the solution:

Best Regards,

[dadreamer]

---

@Luis_AM3C wrote:

          EUREKA!!!! Its posible, only need use a type cast to a normal boolean.

This doesn't work since LabVIEW 2017 as it was considered a bug and fixed. But some other "dirty" hack is possible (only for those, who like to see their LabVIEW crashing 😉). I found that if we alter the mechanical action of a boolean before the Value (Sgnl) call, then no error is generated and the Value (Change) event is fired fine. Interestingly enough there exist three ways to manipulate the mechanical action:

1. Mechanical Action scripting property - works only in Edit mode;

2. Basic Object Flags private property - works only in Edit mode;

3. Get Property / Set Property private methods (with index = 0x6333808) - work in both Edit and Run modes, but not in RTE.

Due to these limitations I did that by tampering with the Object's DataSpace directly. Now works in RTE as well. The VI depends on a couple of helper SubVIs from this thread.

Be warned to not use it in the production, please.

[rolfk]

---

@dadreamer wrote:

---

Be warned to not use it in the production, please.

---

A typical case of:

Patient: "Doctor it hurts when I press on this spot on my body."

Doctor: "Then don't press on that spot!"

The original issue looks more and more to me like the guy who didn't have a ladder with him to fix something on the ceiling and started to staple chairs on each other to get to the ceiling instead of going home and get a ladder. In the hospital he said: "I only wanted to drill a hole in the ceiling for a screw!"

[Basjong53]

The easiest way to trigger an event programmatically is to use dynamic events. You can have the 'Button value change' in the same event case as the dynamic event. The only downside is that you have to keep track of the event reference. You can store it in a state machine shift register, a global variable, an FGV, etc.

[dadreamer]

---

@rolfk wrote:

A typical case of:

Patient: "Doctor it hurts when I press on this spot on my body."

Doctor: "Then don't press on that spot!"

---

Ha! We have a similar joke in my country.

But frankly speaking, I don't see serious reasons, why setting Value (Sgnl) for a latched boolean should be prohibited. It doesn't violate anything in LabVIEW paradigm as X. already stated in that Idea topic. It was just causing a race condition and/or Event undefined behaviour inside LabVIEW internals according to AQ and probably nobody ever cared to figure out why and make a proper fix to it (not a stub condition with an error message as implemented).