Dear Fellow LabVIEW programmers:
Most of the systems you deal with are reactive. It means that their
primary function is constant interaction with their environment by
sending and receiving events. But most likely, they can have something
happening inside them too, even when they are not processing messages
received from outside. So, such systems have to continuosly react to
external and internal stimuli. Right? Moreover, most likely, they
consist of subsystems that are reactive too and, in turn, can have
their own "life", to an extent independent from other parts (with
which they still communicate, of course). Reactive (event-driven)
systems are more naturally modeled with active objects. So, why then
should we try to model and code them with GOOP and its passive
("dead"!) objects?
"Flat" State Machines have been known for decades to have severe
limitations. It's been more than 20 years since Dr. Harel invented
Hierarchical State Machines (statecharts) to fight those limitations.
Then why does NI still tout the same old good Moore FSM as the
ultimate tool for event-driven programming in LabVIEW in its $995
State Diagram KIt?
The LabHSM toolkit we are happy to present, makes it possible to
easily create and then maintain complex event-driven applications in
LabVIEW as a collection of HSM-driven active object VIs using a higher
level of abstraction and agile software development methodologies.
These active object VIs are created based on a universal Hierarchical
State Machine ( HSM or statechart ) template. So. all your code looks
similar regardless of its functionality!
We all love just jump to code, right? However, to be good boys, we
need to do design first. Then implement it in code. If the logic is
modified we need to redo the design first and then redo the code. When
using LabHSM where behavior information is abstracted into a separate
HSM data file editable with a supplied editor, there is no need for
coding separate from design any more. The modified behavior becomes
code automatically as soon as the HSM file is saved. Design is code!
The implementation basically follows Dr. Samek's Quantum Programming
paradigm. (see http://www.quantum-leaps.com). However, as already
mentioned, LabHSM stores the behavior information in a file separate
from the code itself. It also adds state dependent priorities to
events, a separate queue for public events/messages, and, of course,
some LabVIEW specific code like capturing front panel user events and
putting them into the private Events queue. Communication and
instantiation functions are also rather specific for LabVIEW.
It is available for UNLIMITED PERIOD trial. Please visit
http://www.labhsm.com for details and download. The site also contains
references which you may want to check to learn more about
hierarchical state machines and active object computing.
Since this is our debut we will appreciate any comments and
suggestions. Our contact information is available on our site, of
course.
Have a G'day!
