Statechart Module Tips and Tricks

[AlexH]

I've been using the Statechart module for a while now, and find it really useful. I haven't yet seen any discussion of how best to put statecharts into practice (please share a link if there is one).

Some things to discuss:

Synchronous or asynchronous?

How do you call the statechart? What architecture to use?

Passing data in and out of the statechart: Do you stick to the input/output wires, or use other methods like queues, or vi server?

As for me, I have built a couple of really big data acquisition and control systems using synchronous statecharts only. I have a three loop top level VI which deals almost entirely with the user interface. The first is an event loop which deals with button pressing etc., and passes the input cluster to a queue which is read by the second loop. This calls the statechart VI every 100ms or so. It dequeues the input cluster, runs the statechart, and passes the outputs to a third loop using queues. The third loop updates the display.

All of the actual action (DAQ, logging etc.) takes place inside the statechart. As well as using the inputs, I also am using queues to send commands into the statechart (for example to trigger a transition; the queue ensures the command is only carried out once.) Its possible this could be accomplished by using the inbuilt statechart triggers, but I have not tried that yet.

I have found a few difficulties to do with synchronisation of what is going in inside and outside the statechart vi, but in general the Statechart module is incredibly handy.

For interest here is an example of the statechart I am currently working on. (N.b. I'll be using LuaView as well to implement scripting! The lua commands will send a user event to the vi which calls the statechart.). One benefit of the statechart is that it allows you to do tasks in parallel, while communicating over (for example) a single serial port, while not worrying about communication clashes, as each state is executed in sequence.

I'd be very interested to hear about other people's experiences.

Alex

[jgcode]

From chatting with some fellow LAVAers it seems the Statechart module does not get much love. But my collegue has used it quite effectively on multiple RT projects, usually for implementing control.

So I have/can see the benefits and it's something that I have not dived into but I am keen to, one day.

So, whilst I have not much to add, I too am interested on others experiences. One of the downsides is that it's another module to purchase so not everyone has access to it.

[hooovahh]

From chatting with some fellow LAVAers it seems the Statechart module does not get much love.

I totally get the same impression, but have never used it my self. I guess advanced programmers just think they can do it faster and better by them selves. I'm not sure how well my charts would look anyway because large applications tend of have alot of cases for performing specific operations, and I would assume that would make the chart took very cluttered. Like I may have a case for Defer Front Panel, then a case for Get Data, then Write Data to controls, then maybe Change Properties, then Defer Front Panel again, but if I made my own chart for documentation I would make one bubble for Update UI.

As for passing data in and out. Some people use Queues which work well, or functional VIGs, or a combination of a Queue inside a functional VIG with wrappers, or user events, I've never used the Global Variables for such a task because it's hard to track it and find out who is reading or writing to the global at any time. At least with a VIG you can build in some logging to know who is making the writes and reads and setup break points.

[AlexH]

It's true I first used it as part of an educational site license, where we had access to almost all add-on modules, but for my next job where we had to buy a single license, I was persuaded to go for that extra module on top (we have an educational discount, so it is a lot cheaper than the list price).

As for the problem of having lots of individual cases for specific operations, the way I dealt with that, is to create an enum type def for each operation of a certain type (e.g. read a particular measurement quantity). One of the inputs to the statechart is an array of those enums, and in the innards of the statechart one of the subvis cycles through that array, and has a case structure for each possible measurement type. You can add new actions relatively easily by editing the typedef and adding new cases. I'm sure there are other ways to do it (some sort of actions scheduling queue for example). Usually you can categorise your actions into a relatively few types (measurement, control etc.) which means the statechart itself doesn't have to be too complicated.

As for the downsides, statecharts can be a bit slow to edit (it takes a second or two to open state configuration windows), and compiling is fairly slow. They also make things a bit less transparent (I am not sure you can search for vi's within the statechart, and you inevitably add another layer or two of abstraction). The space within the state configuration dialogs sometime be a bit restrictive, so eventually you have to put everything in subvis. Also it seems to crash more often using the statechart than regular labview sessions.

I think its a shame that this is a separate module, since it doesn't give you any more capabilities, just makes life easier, but it is hard to justify the cost unless you have already used it.

p.s. bonus points for anyone guessing what I'm up to in the attached figure above.