LabVIEW
value signaling property node not generating an event
Solved!
@Luis_AM3C wrote:
Hi,
EUREKA!!!! Its posible, only need use a type cast to a normal boolean.
Here the solution:
Best Regards,
Apparently this was a bug, and it got 'fixed'.
It doesn't work (for me) in LV2020.
The cast works, the property node turns into a Boolean (not a variant), but running it returns an error:
LabVIEW: (Hex 0x4A9) When a Boolean control has a latch mechanical action, you cannot use the Value property to read or write its value.
Search LabVIEW like a graph! 
The even simpler solution that will always work is to make the mechanical action "switch when released" and manually set the control to "FALSE" in the event.
@billko wrote:
The even simpler solution that will always work is to make the mechanical action "switch when released" and manually set the control to "FALSE" in the event.
That qualifies as a (good) workaround, not a solution.
It's not always practical or even possible.
For instance, if you want to automatically test an application that has latch buttons. The application is not always allowed to be changed. That could change a 5 min job to a 2 days job (e.g. if the button is in a clone and\or subpanel).
I'll have to read the motivation for this behavior (again).
wiebe@CARYA wrote:
@billko wrote:
The even simpler solution that will always work is to make the mechanical action "switch when released" and manually set the control to "FALSE" in the event.
That qualifies as a (good) workaround, not a solution.
It's not always practical or even possible.
For instance, if you want to automatically test an application that has latch buttons. The application is not always allowed to be changed. That could change a 5 min job to a 2 days job (e.g. if the button is in a clone and\or subpanel).
I'll have to read the motivation for this behavior (again).
@billko wrote:
wiebe@CARYA wrote:
@billko wrote:
The even simpler solution that will always work is to make the mechanical action "switch when released" and manually set the control to "FALSE" in the event.
That qualifies as a (good) workaround, not a solution.
It's not always practical or even possible.
For instance, if you want to automatically test an application that has latch buttons. The application is not always allowed to be changed. That could change a 5 min job to a 2 days job (e.g. if the button is in a clone and\or subpanel).
I'll have to read the motivation for this behavior (again).
Thanks, but that's just silly.
Value (Signaling) gives an error, and the reason given is possible race conditions when reading?
wiebe@CARYA wrote:
@billko wrote:
wiebe@CARYA wrote:
@billko wrote:
The even simpler solution that will always work is to make the mechanical action "switch when released" and manually set the control to "FALSE" in the event.
That qualifies as a (good) workaround, not a solution.
It's not always practical or even possible.
For instance, if you want to automatically test an application that has latch buttons. The application is not always allowed to be changed. That could change a 5 min job to a 2 days job (e.g. if the button is in a clone and\or subpanel).
I'll have to read the motivation for this behavior (again).
Thanks, but that's just silly.
Value (Signaling) gives an error, and the reason given is possible race conditions when reading?
I guess when you trigger the event, it reads the control, right?
I guess when you trigger the event, it reads the control, right?
No these steps are independent. The event gets triggered but does not register as a "read" (else it would reset the switch to the default value). You can easily see that by placing the controls terminal outside the toplevel loop. Even though the event fires, the switch never resets. I can see that allowing local variables and value properties for latch action boolean would be a bit of a can of worms and a lot of things would need to be worked out.
@altenbach wrote:
I guess when you trigger the event, it reads the control, right?No these steps are independent. The event gets triggered but does not register as a "read" (else it would reset the switch to the default value). You can easily see that by placing the controls terminal outside the toplevel loop. Even though the event fires, the switch never resets. I can see that allowing local variables and value properties for latch action boolean would be a bit of a can of worms and a lot of things would need to be worked out.
I forgot about that. The terminal gets read with the event only if the terminal is actually in the event. Thanks for reminding me.
@altenbach wrote:
I guess when you trigger the event, it reads the control, right?No these steps are independent. The event gets triggered but does not register as a "read" (else it would reset the switch to the default value). You can easily see that by placing the controls terminal outside the toplevel loop. Even though the event fires, the switch never resets. I can see that allowing local variables and value properties for latch action boolean would be a bit of a can of worms and a lot of things would need to be worked out.
I'm sure there will be some worms.
I'm doubtful that there will be more worms by allowing this, then by not allowing it.
I usually don't care about the value, or setting it. I just want to be able to trigger the value change, like any other control and indicator.
wiebe@CARYA wrote:
I usually don't care about the value, or setting it. I just want to be able to trigger the value change, like any other control and indicator.
You mean like this? (lots of detailed comments to read ... 😉 )
