statechart module locking up and unusable

[peabody124]

I'm having a strange problem and have no idea how to debug it.  I have a fairly large statechart module controlling a system in matlab on a second computer.  It works great, but every once an a while after running for ~6 hours it will lock up.  I'm using an asynchronous design, so I can see that the loop which processes data and sends triggers is still running, but the loop with the statechart in is not.  In that loop, I set a boolean indicator to true, and then have the terminated? line coming out of the statechart call going into a local variable for that indicator, so I can see that the statechart module doesn't return.  I also have a output string from the statechart that I set to the name of the state I'm currently in, so I can see what state was last entered.  I've gone through all of the transitions out of that statechart and none of them should take any length of time or seems like a good lock up candidate.  Also, there are no static reactions or exit reactions from that state.  I also once saw it lock up in a different state which makes me suspect this is a LV/Statechart module bug.  I just have _no_ idea how to debug this further since there is no way (that I know of) to see what call it is frozen in.  Any help or guidance how to debug this would be sincerely appreciated.

[Matt_W1]

If your running in the development environment and the statechart code generation has debugging enabled. You should be able to right click on the Run Statechart node in your block diagram and select debug statechart, from in there you can use execution highlighting to find the currently running state (I think color of the dot can give you an idea of whether the state is running the entrance, exit or static reaction state). You can also open up the transitions, guards and reactions and use execution highlighting in those.

Matt W

[peabody124]

If I turn that on after the lockup has occurred, will it still tell me what state it is currently in?  At least in normal LV at the top level turning on the highlight execution mode doesn't put the running symbol on vi's that were entered before you clicked the button.  I can't leave it with that mode and wait for the lockup since there is a data processing loop outside that would back up triggers like crazy, and it takes a few hours to occur.

[Matt_W1]

All non active states should be greyed out when you turn on execution highlighting (it at least work for the trivial program I just tried).

Matt W

[otoro]

Following up on Matt W suggestion. Once you have found the state where it get stuck, then you can right click on the state node and select the action VIs. This will allow you to debug the actions LabVIEW code directly.

[peabody124]

So I got the lockup and did that.  One of the states is grayed out, and it has an entry reaction with a generate user event in there and that's it.  Also, I know it finishes entering the state, because that state sets an output indicate that says what state it is in.  That state has no static or exit reactions.  In the transitions I have that, more generate user events, and some code that communicates with another computer - but all of the TCP/IP code has timeouts set.  If it froze in the transition period, would that be indicated, or the state itself? 

The other thing I was wondering about is I feed the user event reference into the state machine inputs, and do nothing with the output of it.  Could this be the problem?  Do I have to take the output reference each time I use it, and then use a StateData field to maintain that?

[otoro]

I am attaching a picture to show you what the debug window look like when:

1. A state is active and evaluating static reactions.

2. A transition coming out of a state is being evaluated.

If you open the debug window and you see that the transition node highlighted then that means you are stuck in the transition node.

With the firing of user event, there is no need to cache in state data, passing as input and firing the event works (since I tried it).

Another thing to check is that what mode is your statechart configured ? Asynchronous or Synchronous. If it is asynchronous are you firing events to the statechart periodically since if you are stop sending events, then the statechart will wait untill a new event is received. This will make it look like it hang inside the statechart, but actually it is only waiting for an event.

Hope this help you to get further.

[peabody124]

So then it's definitely locking up in a state with no static reactions.  I am using an asychronous system and can see that the data processing loop is constantly firing triggers, even after the state chart locks up.  I also set the loop that runs the state chart so it sets an indicator to true when the loop starts, but when the statechart module exits it sets that label to false, so I can see that the labview never completes the call to the statechart.  This seems really strange to me.  The fact I've also seen similar the lockup in other states is making me think it's an underlying bug in LabView SC module.  It will run the same loop for many hours before seizing.  Something I did change recently was passing in a reference to a VI that is called in the state chart, and adding more generate user events - which is why I'm suspicious of those.

[otoro]

Well I cannot think of anything that would went wrong. If you don't mind attaching a snapshot maybe that will help.

One last thing I think you can try: Did your statechart lock up to when you set the Statechart property to disable debugging ? If you have not modified the Statechart property since you created it, then it will have debugging on by default. Try going to the property page and disable debugging, see if you still get a lockup.

[peabody124]

Darn, I thought it was working since it didn't lock up for 2 days with debugging on, but the holiday ended.  The state it locked up in today (i didn't have debugging on, but I set an output when it enters that state so that much I know) doesn't have any static reaction.  Here is the entry action for that state.  Most of the transitions have no action but one makes a call to a counter task so i pasted that code too.  Unfortunately the code is pretty big so I can't really post the whole thing.


Message Edited by peabody124 on 01-28-2008 06:53 PM