Master/Slave Event Structure vs. State Machine

[JoshuaWalker]

Hi,

First some background to the question (Skip this paragraph if you are just interested in the question). I'm fairly new to Labview, having done LabVIEW Core 1, and just a couple of months coding with Labview. Being one of the only people in the company who now knows Labview I have been challenged with creating a relatively complex application that will run a chosen ten or so different tests with customisable options, display readouts, analyse and give results and automate reports.

For the application I am writing I require a GUI with multiple screens (I am achieving this with tabs), at first I tried to code this with event structures inside a state machine (but as you probably know this was fundamentally flawed, as you cannot put event structures inside either case structures, or event structures), but since this point I have spent several hours researching the best alternatives.

My Question therefore is this: would you recommend using a Master/Slave setup (with the event structure and state machine respectively), or just use a continually polling state machine?

(Bear in mind I will be using this as part of a larger Producer/Consumer setup.)

Thanks in Advance,

Joshua Walker.

[crossrulz · Accepted solution]

I use a case in my state machine specifically for checking for GUI events.  This is usually an "Idle" state or a specific "Check for Events" state.  I can also set the timeout programatically using a shift register just in case I need it to do a quick check (some small timeout) or to wait for a user to push a button (timeout is -1).

[JoshuaWalker]

Thanks for your reply

Just to confirm - you're saying you use one case with an event structure inside of it that has its timeout controlled programmatically, and this setup doesn't have the issue where the UI stops responding? (Such as would occur with multiple layered event and case structures.)

[crossrulz]

---

Imaginaryi wrote:

Just to confirm - you're saying you use one case with an event structure inside of it that has its timeout controlled programmatically, and this setup doesn't have the issue where the UI stops responding? (Such as would occur with multiple layered event and case structures.)

---

I don't see any issues.  But I also make sure I run my Idle state every so often to make sure I catch those events.

And if you have long processes, make sure the break those up into smaller states so that you can check for events at a regular rate.

[JoshuaWalker]

Ok, thanks.

BTW, here is an example of the freeze (select motor level then go back to the main menu to freeze the UI).

[crossrulz · Accepted solution]

---

@Imaginaryi wrote:

Ok, thanks.

BTW, here is an example of the freeze (select motor level then go back to the main menu to freeze the UI).

---

Yep, that is mostly due to a setting in the event structure that is on by default for all events.  It is "Lock Front Panel Updates Until Event Case is Complete".  You can uncheck that.  But in general, it is way better if you can use just one event structure that you handle fairly often.

[JoshuaWalker]

Thank-you once again for three very helpful replies.