How to use event structures for long duration tasks

[MinerHokieRamp]

I created a state machine that scans a cluster of Boolean controls in a 'home' state. Most of the states execute a subVI or two in ~100 ms or less.

However, one state executes for up to 10 seconds.

The code is working but the UI is limited as controls are outside the cluster because they provide inputs to the state machine case structure but don't cause changes in state. In other words, I have all the cluster controls stacked vertically on one side of the main panel and don't have the flexibility to move controls to more intuitive positions on the panel.

My question: How can I convert this code to an event structure and keep this long-duration 'event' and prevent the operator from clicking another event button while that event is executing?

Thanks,

[James.M · Accepted solution]

You say you have controls outside your main code... Really you should put these inside and handle them in an Initialization state of your state machine. This allows you to make changes to the code easier and limits the terminals coming in to your loop from outside.

You can do different things to lock the user out.

You can disable specific controls so they can't be clicked or edited.

You could use the Mouse palette to set the cursor to busy and unset it again when done, I do this a lot during processing when my code is loading something the user just clicked on.

One of my favorites is to set a boolean in your data that gets passed through you event structure called "Disable Mouse". When the value is True, a Mouse Down event will dismiss the event, effectively disabling clicking. I also added a Mouse Move event where if the Disable Mouse bool is True, it moves a string indicator along with the mouse telling the user why it's disabled.

If you want more specific suggestions, I suggest posting a Snippet of your code, or attach your VIs, so that we can better assist you.

[MinerHokieRamp]

---

@James.Morriƽ wrote:

You say you have controls outside your main code... Really you should put these inside and handle them in an Initialization state of your state machine. This allows you to make changes to the code easier and limits the terminals coming in to your loop from outside.

You can do different things to lock the user out.

You can disable specific controls so they can't be clicked or edited.

You could use the Mouse palette to set the cursor to busy and unset it again when done, I do this a lot during processing when my code is loading something the user just clicked on.

One of my favorites is to set a boolean in your data that gets passed through you event structure called "Disable Mouse". When the value is True, a Mouse Down event will dismiss the event, effectively disabling clicking. I also added a Mouse Move event where if the Disable Mouse bool is True, it moves a string indicator along with the mouse telling the user why it's disabled.

If you want more specific suggestions, I suggest posting a Snippet of your code, or attach your VIs, so that we can better assist you.

---

Thanks James.

I have non-cluster control and indicator terminals outside the case structure, but they're inside the main while loop. I have a couple of states in the case structure that initialize some of the indicators, property nodes, and boolean texts.

Everything is working so far; the UI needs improvement.

Thanks for the suggestions for locking out the user. That's something I'd do in every event case, then release in the 'timeout' state?

Regards,

[James.M]

You should move those controls inside the event structure. It adds another event case, sure, but it cleans up the code a bit. You can add an event case that handles all of the controls that you don't really care about. This event could simply store th new values in your data cluster. If you don't have a data cluster, then you need too make one. (just a cluster of all your state machine's important data fed through shift registers)

As far as the indicators go, you shouldn't need to write values to them with every state, probably only update their values during specific states, right? You'll find yourself reading from a local variable and writing to the same indicator just to keep the same value the way you have it right now, so just be careful.

You would disable the mouse at the start of the state and re-enable at the end of the state. Careful with doing this for all states, because there are definitely times where you don't want to lock out the user. The little swirly busy cursor gif is annoying if you see it every time you click.

P.S. I'm saying all of this without seeing your exact code, so your application might just be simple enough that you can make do as you are with the controls and indicators.

[mikeporter · Accepted solution]

Combining a state machine with events can be a challenge. Again, as James says it's hard to be specific without seeing your code, but I have always found it effective to build the state machine in the timeout event of an event structure. This structure also makes it easier to handle long timeouts.

One other number to keep in mind: 200 msec. That is how much time you have for your UI to respond to a user input. Take longer than that and people will start worrying that the program has "locked up".

Also check here:

http://www.notatamelion.com/2015/02/23/building-a-proper-labview-state-machine-design-pattern-pt-1/

and

http://www.notatamelion.com/2015/03/02/building-a-proper-labview-state-machine-design-pattern-pt-2/

Mike...

[aputman]

Check out JKI State Machine.  I like it alot, however i have modified it to move the event structure into it's own loop.  I wanted the UI to respond immediately to clicks and key presses. 

[MinerHokieRamp]

---

@James.Morriƽ wrote:

You should move those controls inside the event structure. It adds another event case, sure, but it cleans up the code a bit. You can add an event case that handles all of the controls that you don't really care about. This event could simply store th new values in your data cluster. If you don't have a data cluster, then you need too make one. (just a cluster of all your state machine's important data fed through shift registers)

As far as the indicators go, you shouldn't need to write values to them with every state, probably only update their values during specific states, right? You'll find yourself reading from a local variable and writing to the same indicator just to keep the same value the way you have it right now, so just be careful.

You would disable the mouse at the start of the state and re-enable at the end of the state. Careful with doing this for all states, because there are definitely times where you don't want to lock out the user. The little swirly busy cursor gif is annoying if you see it every time you click.

P.S. I'm saying all of this without seeing your exact code, so your application might just be simple enough that you can make do as you are with the controls and indicators.

---

Thanks.

[James.M]

---

@MinerHokieRamp wrote:

Thanks.

---

Thanks are best given in the form of Kudos and Marked Solutions (Unofficial Forum Rules and Guidelines). You received assistance from some top-tier LabVIEW experts here, whom I'm sure would appreciate your gratitude. Marked Solutions help others find this post when they have the same issue and Kudos motivate us all to keep coming back to help! 

[MinerHokieRamp]

---

@James.Morriƽ wrote:

---

@MinerHokieRamp wrote:

Thanks.

---

Thanks are best given in the form of Kudos and Marked Solutions (Unofficial Forum Rules and Guidelines). You received assistance from some top-tier LabVIEW experts here, whom I'm sure would appreciate your gratitude. Marked Solutions help others find this post when they have the same issue and Kudos motivate us all to keep coming back to help! 

---

Touche'