Statechart locks up after 2^20-1 calls

[peabody124]

I had this old post, but was getting no hits since I found the more specific circumstances.  In my hands, the state machine locks up after 2^20-1 calls and doesn't return.  This can be replicated in a simple test case that I pasted.  Is anyone else seeing this?  It seems like a pretty serious bug.  The test example takes about 40 minutes to run on a 3GHz machine (sorry).

Previous thread:
http://forums.ni.com/ni/board/message?board.id=170&thread.id=296550&view=by_date_ascending&page=2

[otoro]

Hi, this issue has been reported to R&D and under investigation, CAR #97915.

Thanks

[Matt_W1]

This doesn't affect synchronous statecharts, so you can you can use a synchronous statechart with your own queue to work around the problem (I do this with most of my statecharts since it allows me to send parameters with the triggers).

As a side note statecharts with debugging enabled are affected by the UI thread even when in a compiled application.

Matt W

[peabody124]

So when you use events for your own triggers, how is that parsed inside the state chart?  Do you have a super state that responds to the event and puts things on the internal queue, or are there event diagrams in each state?

[Matt_W1]

What I normally use is pretty simply, I have a normal LabVIEW queue that's data type is a cluster of the the statechart's trigger and trigger parameters (if you don't need parameters you can just use the trigger type). Then in the while loop that holds the statechart I dequeue the message, pass the trigger to the trigger input on the (synchronous) statechart, and put the trigger parameters into the input on the statechart (more often the trigger parameters are part of the input cluster so I can pass in additional inputs). If I need the state machine to do work even if there are no triggers (unlike a asynchronous statechart) then I set the deque timeout to 0, and the trigger value will default to null (which gives me a "hybrid" statechart).

If your "upgrading" an asynchronous statechart to this method you wont even have to change the diagram (you'll have to switch it to synchronous and recompile though). Basically all I'm doing is replacing the asynchronous statecharts implicit external queue with an explicit labview queue. Which gives me the advantage of adding trigger parameters if I want (and avoiding the bug you found as well).

Mat W


Message Edited by Matt W on 03-19-2008 06:17 PM

[otoro]

Forwarding a message post on the old thread:

"Hello Peabody124,

Thank you for bringing this behavior to our attention.  With your code and description we were able to reproduce and resolve this behavior.  We were able to produce a patch that you can apply to the LabVIEW Statechart Module 1.0.  See this page on our Drivers and Updates site for the installation details.  Please post back to confirm that the patch works for you.

Let us know if you have any other questions about this.

Regards,
Angela M
Product Support Engineer"