state machine with event structures that share a control

[jgvarner57]

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.

[AnalogKid2DigitalMan]

Hey, that red logo on the right side of the GUI looks familiar to me- Integrated Technology Corp!

https://www.inttechcorp.com/

-AK2DM

[jgvarner57]

Responding to CrossRules:

A UI generally does not need a State Machine.  Hardware interfaces generally do in some shape, form, or fashion.  I generally keep my hardware interfaces running in a form of a Queued Message Handler (some may even call it an Actor), which maintains the state for that interface.  It could signal the UI that something changed and even receive commands from the UI to change its state.  What this does is decouple the hardware from the UI, allowing for easier testing (we can test just the interface without everything else in the system), easier debugging, and more reuse.

This is fascinating and very helpful. Historically I have made my UIs as interactive state machines directly connected to the hardware, but yours is a level of architectural elegance and detachment I would like to explore more. I incorporate a 'debug' option that simulates all the readings I would get from the hardware VIs, but yours is quite interesting.

[jgvarner57]

Responding to AK2DM:

Hey, that red logo on the right side of the GUI looks familiar to me- Integrated Technology Corp!

I have absolutely no idea what you mean {whistles nonchalantly while looking away ... }

[wiebe@CARYA]

---

@jgvarner57 wrote:

I clearly wasn't responding to you, the thread progression makes this obvious.

---

No, it doesn't.

[wiebe@CARYA]

---

@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..

[altenbach]

---

@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]

Responding to altenbach:

No trick. You have to thank me for that feature (suggested in 2009 and implemented in LabVIEW 2013). 

That is an excellent feature. Thank you for that!

[jgvarner57]

Responding to Wiebe:

No, it doesn't.

I realized after I made that comment that you were correct. Most chat threads would show who the reply was in response to, but this one doesn't. I see how people add the comment they are replying to manually (or maybe I am just not doing this right).

[altenbach · Accepted solution]

---

@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. 😄