Strange labview behavour

[jessica_kh]

I have a very complex Vi that runs a complete test system, many databases and functions. It will be impossible to send.

However, the picture shows two state machines, when the first state machine is in PRO, there is a second state machine.

The event on the left controls the first SM there is a second event controlling the second SM. it also be seen that the second SM cannot be entered as there is a false Boolean into the case structure, the state of false is in all event cases.

Pressing close button freezes all labview windows, it does sometimes release to the point of being able to abort.

Removing the second SM while loop (bearing in mind it is not active allows the vi to be closed and also all the other functions of the first SM are functional. 

Also if I disconnect the boolean selecting the second SM and replace it with hard wired boolean it also functions.

Any thoughts?

Any suggestions on how to debug?

Thanks Jessica

[RTSLVU]

Well without seeing all of your code we can only guess, but at first glance of the pictures it looks like your overall architecture is flawed. All those nested cases, loops, and Event Structures inside One Big Loop.

To get into details we will need to see all of your LabVIEW code.

[JÞB · Accepted solution]

OK Jessica I'll shake my magic 8-Ball here ~~~~~

     I will bet you money, marbles or ice-cream, at any odds, that LabVIEW is operating EXACTLY how you programmed it to behave!

My 8-Ball says:

• First, check the mechanical action of the Close Control.  Since you have a Mouse Up Event on it and do not read the terminal in that event case, it should probably be Switch when Released.  Alternatively,  Read the terminal in that event and Latch when released.  Something stinks there regardless. 
• Next, look at all the nested While loop conditional terminals.  My Magic 8-Ball says there is either an infinite loop or a greedy loop or both lying in wait like a lion to bite you. 
• While you're at it, since you are using at least one local variable, watch out for race conditions around the loop conditional terminals.  That's how lions get to eat all those silly gazelles that weren't looking close enough for the race conditions.
• Finally, check each Event Case setting for the Lock FP until complete option.  That one is a well known snake in the grass.

[jessica_kh]

The problem was due to events on buttons, this was the area I was updating, I reverted to the original non-event method all was functioning again.

So looking at the events, I am saw that most buttons generated a single event, when there is a lockup the button has generated multiple events and leaving one or more on the unhandled queue. This was traced to an event that should not have had the button case.

Thank you for help in putting me in the right direction

Jessica