STATE-EVENT machine causing FREEZE executable VI

[JLuna]

Hello all. I have a slight problem that I have not been able to pull it out, for just about a couple of months now... The executable of this VI, just

freezes randomly and I do not know why. I've tried many fixes in my code, and still the problem persists.

I attached some images instead of code, because I have many subVI's. I don't know if I upload the whole project, you are going to be able to

reproduce it. Funny thing when I'm debugging, this error (freeze) won't appear.

Basically my code is based on STATE-EVENT architecture. Inside two states I have and event on each state. In this two events I'm waiting

for a code to be scanned (control string receives code) and after this event is generate I exit the respective event and go to another state in the

state machine. So my guess is like this:

States                                   Event             Status

WAIT SnorkelDummy           Yes                 OK

WRITE SnorkelDummy        No                 OK      

WAIT Blower                        Yes                 I'm guessing that here the error comes, and VI freezes

WRITE Blower                      No                  I think the problem is not produce here, because no

                                                                    event is in this state.

Can someone PLEASE help me with this issue. I'm driving nuts here!!

[Gregory · Accepted solution]

With event structures, it is possible to lock the front panel until an event is handled. For instance, if you're not in the "Wait Blower" state but you change the "Blower WR" value, it could lock up your front panel until that event is handled, which may be never, locking your UI. If you edit the event structure you can see if "Lock panel" is checked or not.

In general, it is good to only have a single event structure to make it harder to run into this situation.

[JLuna]

Based on your statement, I still don't understand how can the Blower WR state change if:

• Blower WR Control is hidden
• To be able to write to this control, the key focus property is inside an specific 'state machine'. So this control is practically available until the program enters this state.
• Once the program is inside this 'state machine' the event can now happen, but only just until this situations completes.

So, I'm still wondering how does it activates (as you mention) and locks my UI.

Anyhow, just as one more test... I'm going to follow your advice to have only 1 'event structure' and see how this works. I attached a screenshot

of the part of the code I replaced with a while loop; just waiting for a 'value BLOWER WR' to happen.

Thanks for you reply.

[dkfire]

You clearly have race condition and DATA FLOW problem. 

Run your code with Execution highlight and it will be clear to you. 

You are read the string control Blower WR when the loop starts, and just before your loop can iterate you clear the control again. You will alway read an empty string from the control. 

[JLuna]

I don't think it's race condition. Because inside event 'BLOWER value change' I save the new value in a cluster. When the event loop exits, I clear

the control value for next iteration.

also this issue I'm having just happens randomly. It could happen only once per day or it can even pass 3 days with no error, then at the 4th it appears. So weird. I'm going to testing first. Then evaluate and see the outcome. I'll be posting for any news.

Thanks for your answer by the way, I really appreciate it.

[JÞB]

Just attach a snippet of the top level vi.  I'm not concerned about the missing sub-vis but your pictures just don't show all the settings.

[JLuna]

Here is the MAIN vi.

Take a look. Many thanks by the way.

[JÞB]

I'm not seeing too many real flow control problems however,

That is the darndest way to set the "blinking" property on controls I've ever seen. (that took me a while to figure out what you were doing)

Check your file data for whitespaces.  or use trim whitespace when you load "Muestra Patrón" into that string array portion of the unnamed cluster.  (Make that cluster a type def!)

[JLuna]

Hahaha , is there another way to set "blinking" property on controls? a more effective way? Now that you mention, is there

any problem with memory usage, while calling every 100 ms the property "blinking" or any other property node?

What are the pros making the cluster type def? Does work similar when making a state machine 'control' typedef (updates automatically when

adding more states)?

Since the last major update about my VI, the problem has not appeared. I'll keep posting updates.

[JÞB]

---

@JLuna wrote:

Hahaha , is there another way to set "blinking" property on controls? a more effective way? Yes use a property node for the indicator or control you want to blink or not blink an write a boolean to the blinking property Now that you mention, is there

any problem with memory usage, while calling every 100 ms the property "blinking" or any other property node? Yes, it requires the User Interface Thread and that makes the UI slower.  So, don't repeatedly update things that can be set on an event or set and reset inside a long state

What are the pros making the cluster type def? Does work similar when making a state machine 'control' typedef (updates automatically when

adding more states)? Absolutely!  What happens if you change the Clusters array of strings to a cluster of 3 labeled strings and an I32? Damn! that would almost document your config file format wouldn't it?

Since the last major update about my VI, the problem has not appeared. I'll keep posting updates.

---

By the way, Consider getting rid of all those "useless" controls that are only there for data entry and toss up a Prompt User.vi (Express vi's aren't totally evil and that one would save you a S#!tload of funky and hard to debug code.