The webpage at http://zone.ni.com/devzone/cda/tut/p/id/11123 warns against setting Boolean controls to latch mechanical actions:
"One important note: For boolean controls on the front panel, they must be set to a switch mechanical action. Creating booleans that use latch mechanical actions will lead to improper behavior in NI VeriStand, and will result in an error within the custom control."
So unfortunately this does not appear to be a viable option...
After working with the developer we found that there is a race condition then using Boolean controls with this framework. The race condition can lead to the stuck action that you and I are seeing. We do not have a fix for the issue, but the quickest/easiest work around is to use numeric controls instead of Booleans.
We may have found a work around for this issue. If you keep track New Value through an array and a shift register you may be able to accurately track the value change without rewriting the value. I have submitted screenshots which explain the changes that should be made to track the value change. Try that out and respond back with how it works.
Thanks for providing the suggestion and screenshots.
I have given it a try and unfortunately it does not quite work. Certainly the boolean buttons will not get stuck now, but they are not sending the proper control value to the indicator.
I have attached the relevent files for your diagnosis. Basically you will see that the boolean indicator is not changing state when the boolean buttons are pressed.
Some side questions on the Reference Configurable Custom Control:
When does the initialisation portion of the block diagram gets executed? Everytime VeriStand restarts or every time you change to a different screen and back again? Does exiting the VeriStand workspace into the NI VeriStand - Getting Started window causes the middle event handling while loop to be terminated?
The initialisation gets called when the Workspace is started. When you move between screens the VIs that are the controls/indicators are still running in the background. When you go back to the Getting Started window the VIs are closed.
As for the bottons not sending values, it looks like another screenshot is need to so other wires, please see below. This worked for me, let me know if this resolves the issue.
Yes, it works brilliantly now. However, I have noticed the buttons still get stuck when the event timeout is reduced from 200ms to 50ms in an attempt to make the buttons respond quicker as suggested in an earlier post.
Back to the side question, if I have several screens each containing its own Reference Configurable Custom Control, do the initialisation codes in all screens gets executed when Workspace is started? Or only the initialisation code of the first active screen gets executed when Workspace is started, whilst the initialisation code for other screens will only get executed when the corresponding screens are made active the first time?