User Input State Machine does not work as expected - unsure what to do

[ijustlovemath]

Hi all,

I'm designing a UI for a program I wrote and trying to implement it with a state machine. The machine doesn't really work at all; it just transitions between states without seemingly doing the checks it should be doing. Before I added the wait (for debugging), it would work as expected, until I'd changed two values, then the whole thing would freeze. Also, no matter how I set the Window Appearance settings, the abort button has gone away when running this VI.

This input should basically run the user inputs through a series of checks to make sure they're entering sensical data, before sending it out to the main VI. One problem I have is that range_min and range_max are interdependent with their checks:

1. They must both be positive, and nonzero
2. range_min must be less than range_max
3. range_max - range_min must be greater than or equal to 40.

It seems this interdependence is what causes the crash when removing the wait statement, but I can't be sure.

I've attached a zip containing the VI so you might check it out. Let me know what you think.

[RavensFan]

Your zip file is corrupt and won't open.

You need to try attaching it again.

[ijustlovemath]

Very strange. Spot checked this one, it seems to work:

[crossrulz]

1. There is no reason at all for the event structure in the Initialization state.  In fact, that is what is causing your freeze.

2. You should probably be going back to the Default state from the Good Check state.  You currently have it going back to the Initialization state.

3. There is no need for the sequence structure in the Good Check state.

4. Please do NOT use the Quit LabVIEW function.  I do not like my LabVIEW being shut down on me while I am developing.  I am assuming this is part of a larger application, so you might want to pass out an error or some flag telling the application to shut down.

5. To be completely honest, I don't even see a need for a state machine here.  Your checks could be done inside of the event structure and it would simplify things quite a bit.

[RavensFan]

Here are a few problems  I see.

1.  Why is the abort button not showing?  I know you may not want it in your final application, but while you are debugging, you need it.  How do you stop your VI when it locks up?  I was forced to use a utility I found on the forums to abort a running VI in order to get my LabVIEW back.

2.  You have several states that have an event structure in them.  Event structures capture events even when they are not in the line of execution.

You should read. Caveats and Recommendations when Using Events in LabVIEW

"It's not impossible to have multiple event structures, but unless you really, really know what you are doing, then you are going to mess them up. "  - LabVIEW proverb

3.  Your events are set to lock the front panel until the event case is completed.  That is what caused my LabVIEW to lock up.  I hit the Cancel button which locked the front panel.  But because the state machine case which would have handled that event was not in the line of execution (maybe it would have required another button to be pressed first, I don't know, I can't follow the logic), the VI effectively locked up because of this and #2.

4.  What is the logic flow of your VI?  It is a good idea to create a state diagram that shows each state and the actions that would lead you from one state to another.

5.  You have event structures that have a timeout case, but yet you have no timeout value wired to them.  The timeout case will never executue.

[ijustlovemath]

crossrulz,

• my apologies for having that "Quit Labview" in there. That was bad form.
• I have tried to handle this in an event structure, but couldn't quite figure out how best to do what I did in the "value check" state. By the way, was that a good way to handle it? I thought I was getting a little carried away with the for loops, but I wanted to do something more general.
• In that regard, is there any way to auto-populate the second-innermost case statement with the labels of the controls as cases?
• I put the sequence structure in because I couldn't see a way to enforce execution order, although I see your point, as the execution order doesn't really matter!
• Could you expand on the "proper" way to handle #4? Short of using a "quit labview," I don't really know how to handle this gracefully.

RavensFan,

• I'm trying to figure that out myself, as I made sure the "window appearance" has the abort button showing. Maybe it didn't save? Not sure.
• Good point on 2. I didn't know that about event structures! I think the fact that there were two of them looking for "Value Change" on "Constants.Controls[]" is what caused the freeze.
• Is it bad practice to not use the timeout state? I don't forsee the need to do that, but maybe I'm wrong. I put stuff in the timeout state to make sure the structure tunnel had all cases filled.
• For 3, is that a setting I can change on the event structure? Where would I find that?
• For 4, the flow is like this: https://i.imgur.com/gwYKYyC.png

As always, thanks for your help. This forum is an LV noob's dream!

[RavensFan]

---

@ijustlovemath wrote:

RavensFan,

• I'm trying to figure that out myself, as I made sure the "window appearance" has the abort button showing. Maybe it didn't save? Not sure.

Perhaps.  All I know was the abort button wasn't showing once I ran it and needed to abort the stuck VI.

• Good point on 2. I didn't know that about event structures! I think the fact that there were two of them looking for "Value Change" on "Constants.Controls[]" is what caused the freeze.

That is probably part of what caused the problem.  You can have two of them looking at the same event.  When that happens both will queue it up.  Once the event structure is in line for execution, then it will execute the queued up event case.  That along with #3 with locking the front panel.  Both event cases would lock the front panel.  Only if the event structures were able to execute without the user needing to do anything else (which he can't be the the FP is locked) would both event structures be able to handle their respective queued up events and then unlock the FP.

• Is it bad practice to not use the timeout state? I don't forsee the need to do that, but maybe I'm wrong. I put stuff in the timeout state to make sure the structure tunnel had all cases filled.

Timeout case is fine to use.  But if you dont' wire a value into the timeout node to the upper left, it can never execute.  Then there is no point in even having that timeout case.  You can delete the timeout case from the event structure.

• For 3, is that a setting I can change on the event structure? Where would I find that?

Right click on the event case and pick Edit Events for this Case....   It is a checkbox near the bottom of the dialog.  By default it is set to lock the front panel.  I feel that is a poor choice for default because it winds up messing up more new users who don't understand event structures.  You can tell by how many questions are asked and answered in the forums where "my VI is locked" and the answer is related to that setting.  The only good thing, I guess, is that when it messes people up, it forces them to learn more about event structures, but only after they are aggravated.  I'm not sure exactly have having the checked by default helps people.

• For 4, the flow is like this: https://i.imgur.com/gwYKYyC.png

Yes.  That is exactly it.  Just be sure that as you mentally step through your program, the way you have it programmed will actually follow the path that you have drawn out.

As always, thanks for your help. This forum is an LV noob's dream!

---

[billko]

To that end, you can either single step or use highlight execution to see exactly what states are being executed in what order.

[crossrulz]

---

ijustlovemath wrote:

• I have tried to handle this in an event structure, but couldn't quite figure out how best to do what I did in the "value check" state. By the way, was that a good way to handle it? I thought I was getting a little carried away with the for loops, but I wanted to do something more general.
• In that regard, is there any way to auto-populate the second-innermost case statement with the labels of the controls as cases?

---

That value check state is a complete mess with imbedded case structures and it just gets really messy very quick and becomes really hard to read.

I'm going to go back to the fact that you do not need a state machine here.  You can have the Event Structure key off of any of the controls inside of the cluster.  So make an event case for each of the controls so that you can check them when they are changed.  Many of those controls get the same checks, so you have a single event case handle many of the value changes.  (See Attached)

[ijustlovemath]

Crossrulz, your implementation makes a lot of sense! I never knew what ctrlref did, that's handy. One weird thing is that when I initialize the Boolean array with trues, the button doesn't go to continue, presumably because I have to manually change each input before it gets set to false. Is there any way to set some (read: most) controls as having acceptable defaults, and therefore not needing to be changed to be okay? Also, why can't references be included in subVIs (from the Edit - create subvi menu)?