Statechart module is not debuggable...

[AgB2]

Hello,

   I have a statechart which compiles ok (TMS_SM included), but when I attempt to run it/call it from a "Run StateChart" call  it comes back with a Block Diagram error:

" Run Statechart: XNode is not executable"

There appears to be no way to debug this problem directly (I have deleted all the changes that I had made since it previously worked, and tried removing all the 'odd' controls from in Inputs.ctl and Outputs.ctl to no avail).

Thanks

Andrew

[BenDAE]

Regardless of programming error you're correct that you should be able to debug. I tried to run it on my computer, but it was missing TMS.lvclass. So I was unable. I checked your triggers and none showed up. I'm guessing the file has become corrupt. I would try to build a simple statechart and test to see that it's not the entire module that's the issue.

Thanks,

[AgB2]

Hi Ben,

  thanks for your reply, I have tried it with another statechart and the same class and it works ok. I've decided to abandon using the statechart module - whilst it is useful in some aspects it isn't well integrated with the rest of the system and the programming paradigm appears to make solving some problems more complex. Couple this with the fact that it either fails corrupt and is not easily (or at all in this case) makes this package an unacceptable risk for me, unless I am missing something significant - do you know of any projects/people who are using this module and are better off with it?

Andrew

[Wee-Bey]

Hi there Andrew. I'm a colleague of Ben's. The statechart module is especially useful for extremely complex applications. Some people use it to design projects around FPGA and embedded applications, and this software can help a lot with that. It becomes very useful in the long-term for these kinds of projects. It depends on your application, but there are definitely also times when you can use an alternative.

[AgB2]

Thanks Ravi,

   my application requires a complex set of states so for the purpose of visualization the statechart was good (although limited in its constructs), my issues are largely related to the ease of  access, debugging, tracing, transparency (particularly for entry/exit/static reactions) and reliabililty (when the statechart compiles but fails to run and provides only a generic error with no indication of what the problem is and doesn't appear to recover on reverting) of the technology. Maybe I'm using the module incorrectly if you are happily/successfully using it for complex solutions - do you have any complex examples (all the examples I have seen are simple with 4 states and not many entry/exit/static actions), have you experienced the reliability problems I've mentioned and how do you debug guards and entry/exit/static reactions in a complex state diagram?

thanks

Andrew

[Wee-Bey]

I don't have any complex examples on me, but before we go in that direction, are you using an Xnode on your statechart in the VI? I'm sorting through it and not seeing any. LabVIEW does not support XNodes, and that might be why you're seeing that particular error. Are you getting any other performance issues?

http://zone.ni.com/reference/en-XX/help/371361H-01/lverror/edxnodebadgeneratedcode/

[AgB2]

Hi Ravi,

   at one stage the Statechart did work so it can't be an xnode problem (and I removed all references to 'exotic' items such as references, objects etc.). Don't worry about debugging it as I have already abandoned that statechart, I was more interested in knowing about your experience with complex state systems and the statechart, I still need an intermediate 'tool' to assist in building solutions from a specification and Symbio's UML tool doesn't generate state diagrams and the benefits of the statechart module don't compensate for the various issues that it has created on my system, so I'm back to just implementing state diagrams.

Andrew

[Matt_W1]

I'm quite happy with the statechart module, My main program has three statechart's, two of which I would say are more complicated than yours. Mine have fewer states but they use more advanced features (hierarchical states being a big one) and have a lot more reactions. Really complicated state systems are much easy with the module in my experience (but I'm directly modeling them in the statechart instead of trying to translate UML). But you need to understanding how exactly the order and how  entry, exit, reactions and transitions are handled, to take full advantage of statecharts.

Some useful tricks I've used are:

Hierarchical states, combined with entry and exit actions, allow for easy acquisition and release of different resources, or resetting statedata.

Reactions are often a simpler solution to transitions.

Outputs can be used just like StateData, in other words they they hold there value between evaluations of the state chart.

You can set the priority of exit transitions, which is handy to choose states based on guards instead of triggers.

It's been a few LabVIEW versions since I needed to really work with them, so my knowledge is a bit rusty, so this might not be quite right.

Sometimes I would have to Force regeneration to locate errors (may no longer be an issue)

Debugging used (I assume it still does) to force the statechart to depend on UI Thread (even in a compiled program), so I would always turn off debugging when I didn't need it.

Pushing something on the internal queue forces an additional evaluation step (this can be used to make temporary states, that don't have to handle external triggers)

I dug up some of my older posts where my knowledge was fresh (I believe the call limit bug has been fixed, but it didn't apply to my method hybrid of using statecharts)

One of my old posts where I talk about my hybrid statecharts architecture

http://forums.ni.com/t5/LabVIEW/Statechart-locks-up-after-2-20-1-calls/m-p/674145/highlight/true#M30...

And a post dealing with debugging statecharts.

http://forums.ni.com/t5/LabVIEW/statechart-module-locking-up-and-unusable/td-p/641814/highlight/true

I tried to look at your example but their missing pieces so I can't try to figure out the bug. I would try an older version, to check if something got corrupted (I think I've only had VI's corrupt on me, but those can create nasty bugs), if you don't have a version control system I strongly suggest you get one. I get Xnode errors trying to open statecharts on system with out the statechart module, but it sounds like you have the module installed. The statechart isn't brought up too often on the forums so I suspect it's an uncommon module for people to use.

[AgB2]

Thanks Matt,

   you mentioned understanding exactly the order entry, exit, reactions and transitions - this is where it gets messy for me when there is a problem, as I can't open and display what is happening during the debug cycle and I have to print out (html->paper) the states functionality to track what is/might be going on. But it falls over entirely when the there is no traceability on the error.

cheers