why so little love for statecharts

[MarkCG]

I believe this NI addon is very unappreciated. I am using it right now to a production machine with multiple stations for a customer. No specs provided beyond asking "what should it do if X" and boy howdy-- doing things in term of statecharts is had made thinking about the problem and crystallizing the logic an absolute breeze. it is also easy to test the logic encoded in the statechart. 

 

Doing the problem in terms of a conventional LabVIEW "state machine"  would be much less fun and take longer. 

 

There are of course, some bugs as you might expect for such a little used module, some causing hard crashes of the dev environment during edit time. 

 

What is it in your opinion that has turned people off LabVIEW statecharts? Is it the the statechart paradigm and the need to learn it? Or the perception that it's just re-inventing the wheel? Or the bugginess and half-finished quality of the module?

[JKSH]

What is it in your opinion that has turned people off LabVIEW statecharts? Is it the the statechart paradigm and the need to learn it? Or the perception that it's just re-inventing the wheel? Or the bugginess and half-finished quality of the module?

 

I think it's a chicken-and-egg problem: NI doesn't polish it because there are few users; few users use it because it's not polished. I don't think it's the learning curve because the concept of statecharts is quite intuitive, and should be familiar to many people who haven't used LabVIEW before.

 

I used statecharts for one large project once, for coding complex logic in a CompactRIO. The main issues I had were:

• Deployment took forever.
• Bugginess, like you said.
• Modifying triggers is tedious (and you can't share triggers between different statecharts)
• Managing static reactions is tedious (you can't reorder them or insert a new one in the middle; you gotta delete them and re-add them in the correct order)

[ShaunR]

Because state-machines are hard and have to be debugged with witchcraft. So just avoiding the problem means you don't need tools for that problem.

Edited July 14, 2015 by ShaunR

[infinitenothing]

Primarily, $1555

[MarkCG]

 

I think it's a chicken-and-egg problem: NI doesn't polish it because there are few users; few users use it because it's not polished. I don't think it's the learning curve because the concept of statecharts is quite intuitive, and should be familiar to many people who haven't used LabVIEW before.

 

I used statecharts for one large project once, for coding complex logic in a CompactRIO. The main issues I had were:

• Deployment took forever.
• Bugginess, like you said.
• Modifying triggers is tedious (and you can't share triggers between different statecharts)
• Managing static reactions is tedious (you can't reorder them or insert a new one in the middle; you gotta delete them and re-add them in the correct order)

 

 

Yes deployment is a little long when using interactive mode, not too bad now with newer version of LVRT where it only deploys VIs that have changed after initial deploy.

 

The bugginess is annoying but I have figured out how to avoid the crashes in edit time. I'm pretty sure I can reproduce on way to make LV hard crash when editing statecharts, but I wonder if NI would care if I did document it...

 

I also was surprised you couldn't rearrange triggers and static reactions. I just decided I would never rearrange them and deal with it. That's part of the lack of polish for sure.

 

Primarily, $1555

 

Yes. That's a big one. I wish NI would give up and include it with the full development system.

 

 

Because state-machines are hard and have to be debugged with witchcraft. So just avoiding the problem means you don't need tools for that problem.

 

I'm a witch doctor and my magic is strong. Seriously though- I have read some things from functional programming decrying the existence of "state" in programs. But my view of the matter is that the state of the physical system you are controlling needs to be reflected in the computer to be able to do anything useful. Almost always the state of the system is dependent on is prior history and what you can do next is dependent on that.

 

I don't see what are talking about, when applied to programs that control a machine in the real world. But I am starting to read about it Functional Programming, maybe it'll reveal the answer as to how to avoid the problem!

[ShaunR]

I don't see what are talking about, when applied to programs that control a machine in the real world. But I am starting to read about it Functional Programming, maybe it'll reveal the answer as to how to avoid the problem!

 

LabVIEW is a Dataflow language rather than Functional Programming. State is implicit rather than explicit and execution is inherently parallel - it is quite a different beast to Functional Programming.That's not to say you don't need a state-machine at some level to control execution. In the LabVIEW world it is usually a sequence engine which is a lot simpler since LabVIEW execution can be represented as a directed graph and that is basically your block diagram.

[smithd]

I'm a witch doctor and my magic is strong. Seriously though- I have read some things from functional programming decrying the existence of "state" in programs. But my view of the matter is that the state of the physical system you are controlling needs to be reflected in the computer to be able to do anything useful. Almost always the state of the system is dependent on is prior history and what you can do next is dependent on that.

 

I don't see what are talking about, when applied to programs that control a machine in the real world. But I am starting to read about it Functional Programming, maybe it'll reveal the answer as to how to avoid the problem!

 

The way I interpret some of that stuff is that state isn't evil, its the combination of state and action. For example, consider the difference in labview between a subVI which includes an uninitialized shift register vs one which simply takes data in (from wherever), processes it, and returns a result (to wherever). The second is a whole lot easier to understand, to prove correct, and to test. There is still state, its just been moved up a level or two or.... Also, I personally found this paper interesting and very helpful in understanding those functional programming crazies.

[BradPID]

Although the concept of Statecharts is old, I think, that still not many people know it. Most of LV users are engineers and scientiests who get their 'software engineering' knowledge (like me) while working, when it is required and not from computer science courses where this concept is a basic one. I think NI would have to make a move in order to make them more popular.