LabVIEW
state machine with event structures that share a control
Solved!
Responding to CrossRulez:
This is my project UI that controls a system with 16 independent stations that measure up to 100 DUTs each. In the 'test state' it is monitoring and logging currents and temperatures of up to 1,600 DUTS, at a rate of 16 per second but one at a time, thus the 50ms timeout as things are happening even when it is waiting for user events. The user can switch between a 'setup state' and a 'test state' at any time, and all these controls are used very differently between the 'test state' and the 'setup state'. Clearly I need to have full UI interaction in either state, and the 'quit' button should close the program down safely as I have about 1000W running this.
I said all this before, but people only focused on my little model and not my original question. I took this project over from someone else who was using so much inefficient and redundant code I could have wallpapered my entire lab with the block diagram. I have this entire system cut down to a more dynamic and polymorphic structure like what I simulated with my little model. Anyway, I couldn't find anything on the forums about multiple event structures in a state machine that shares controls, and now I have provided one.
BTW, the trick to making this work was simply this:
This is what fixed my problem.
@jgvarner57 wrote:
I'm done here.
ok...
But please do accept your post as solution:
@jgvarner57 wrote:
BTW, the trick to making this work was simply this:
This is what fixed my problem.
Others might find your solution helpful 👍.
And just hope you never need a user (or dynamically registered) event, because that will complicate things a lot..
@jgvarner57 wrote:
BTW, the trick to making this work was simply this:
This is what fixed my problem.
No trick. You have to thank me for that feature (suggested in 2009 and implemented in LabVIEW 2013). 😄
@jgvarner57 wrote:
, but the automatic handling of "latched when released" was not very elegant, and quite unpredictable, when it came to the states of the controls.
The reason is that latch action button reset to the default state when they are read by the code, meaning they need to be inside their respective events (even if not wired to anything) . If you have them outside the toplevel loop as you currently do, they will only get read once at the start of the program and will never reset again.
While I understand that your attached code is just a simplified mockup of the real thing, I see the following problem.
- Property nodes are synchronous, forcing a thread switch and are thus expensive.
- Having overlapping controls and constantly playing hide&seek with controls on top of each other is a nightmare during editing. All you need is one button where you change the boolean text. (Scalability is the key! Imagine if you have 10 states in the next project. How are you ever going to edit them??? Herding cats!)
Here's a quick draft that shows some alternatives. Maybe you can adapt some of the ideas to your code. It would be easy to expand for much more advanced functionality, e.g. trigger a queue handled elsewhere in a parallel loop, etc.
- One while loop with one single event structure containing one single event case! (Flat code, nothing hidden in other cases, etc.)
- Clear list of actions that can be expanded by adding more elements to the cluster.
- All buttons are latch action
- Three booleans instead of four.
- One property node instead of 28(!). Good unless you get paid by the number of property nodes. 😄
