Comments for StateWORKS Blog

Comment on What is a state machine? by Joe

Joe — Wed, 15 Sep 2010 17:51:43 +0000

It’s been two years since first time I left a comment here. Recently, I happened to trace complete event-driven system programs. Suddenly I had the sense that why you do not like event driven stuff. Event itself is not a problem but software nowadays handles it using call backs. One call back tries to trigger another call back, or tries to communicate with another call back. System control logic is distributed among call backs. In some way, it’s like system control logic is distributed among threads. Quite complex.

After two years, I finally understood some things. I found sequential logic is simpler than concurrent logic. Use sequential and centralized logic whenever possible and use concurrent logic only when necessary.

Another difficulty I found: sometimes same data must be handled by different actions(or different sorts of ‘clients’) and each action has different timings. Then making concurrent asynchronous access mechanism for the data may be a good thing, or the chaining actions for the data may become quite complex.

Comment on Calculator by Gordon Morrison

Gordon Morrison — Fri, 30 Jul 2010 15:08:15 +0000

Using my COSA state machine I have developed a 5-function calculator that uses only 28 logical tests. I can perform the following calculation -3.14159 – -2.14159 in 28 logical tests. That’s 18 entries in 28 logical steps or 64% efficient counting every test; “if/case/?/etc.”. Miro Samek takes 96 logical tests 20% efficiency and Ken Pugh takes 75 logical tests 24% efficiency. If you want to prove you are indeed in the silver bullet category take my challenge and publish your results. I will add your company to my challenge list at http://www.vsmerlot.com. My book is Breaking the Time Barrier-The Temporal Engineering of Software.

Comment on What is a state machine? by admin

admin — Sun, 25 Jul 2010 07:31:38 +0000

You are right. A network of communicating state machines each in its own thread without a clear logical structure is a nightmare and must end in a disaster. In the VFSM concept and its StateWORKS implementation we try to show that the proper way of designing a system of state machines is the hierarchical structure. It is less a problem of having the state machines in one or more threads but the the logical design plays a decisive role. In the StateWORKS implementation all state machines are per definition in one thread anyway.

Comment on What is a state machine? by Toronto Condo Staging

Toronto Condo Staging — Sat, 24 Jul 2010 15:57:35 +0000

If we design a set of state machines each solving a partial problem without having in mind from the beginning the entire logical structure we may end in a difficult fight with deadlocks and nondeterministic behavior by implementation.
Keeping state machines in one thread simplifies a lot.

Comment on Introducing “Questions” by John M

John M — Tue, 30 Mar 2010 04:48:21 +0000

I see what you mean about increasingly diminished comprehensibility. (I have enough trouble remembering the scenario of a controller watching a panel of instruments and taking actions iteratively and in a possibly non-linear / sequential manner. The ’sequential programmer’ nature runs deep!) A changeable execution engine would be unworkable!

To move to a Moore model, an input condition of the Mealy (mixed?) model would be tested in a transition condition and if True the to-state entry actions would execute the input actions? I’ll take a look at it – thanks.

Comment on Introducing “Questions” by ferdinand

ferdinand — Sun, 28 Mar 2010 08:50:59 +0000

The present VFSM execution model is a result of several years of discussion and practical experiences. Your ideas could be implemented but there is one basic difficulty: the comprehensibility, especially if the model could be changed at any time. We allow it with the break state but we use it with care. Imagine that you have several possibilities to change the model according to problems you presented. The state machine will become as difficult to read as a coded implementation.
I believe you should just use a simple model like a a Moore one to solve your problem. It will increase the number of states but you will understand what you are doing. The combination of Moore and Mealy model seems to be attractive but all experiences show that the design becomes complicated in spite of less states.

Comment on Introducing “Questions” by John M

John M — Thu, 25 Mar 2010 06:19:18 +0000

Technical Note 25 re “break states” looks very useful! I am wondering whether the idea could be applied to each transition rather than all the transitions from the _B_ tagged state?

Anyway, how about the similar idea of a state change that executes the input actions of the to- state rather than the entry actions – or maybe the entry actions then immediately the input actions before the transitions?

I’m trying handle 2 disjoint sets of logic via a “switch state” – rather than have a single state and pre-fix every condition expression with either “LogicSwitch_HIGH” or “LogicSwitch_LOW”. So the switcher state has only transitions to either a LogicHigh or LogicLow state.

Now the ‘real’ stuff in those 2 states is in input condition /actions but to execute those I need to make some kind of “change VI just to get input actions to execute” entry action …. and also make sure none of the LogicXxxx state transitions trigger until I want them to (ie after the input actions have executed).

Some kind of “let transition to- state handle the latest VI change” transition would make life easier …. or is there another better way to handle this?

Comment on Introducing “Questions” by ferdinand

ferdinand — Mon, 15 Feb 2010 08:02:50 +0000

Exactly. The changes of the virtual input can be done by the I/O Handler and by the outputs of the executed state machine.

Comment on Introducing “Questions” by John M

John M — Mon, 15 Feb 2010 03:37:54 +0000

Thanks – must confess I was thinking single state machine only. I suppose in any case one needs to be aware of the principle of *continuous* monitoring of inputs? The input values to even a single state machine could change in the middle of control logic execution – yes?

Comment on Introducing “Questions” by ferdinand

ferdinand — Wed, 10 Feb 2010 12:54:56 +0000

John,
Yes, there is a reason for this solution. While the Executor is processing a state machine the virtual input of this state machine may change. Thus this state machine will be put into Executor queue. If the Executor uses the virtual input (and not the copy) the situation will be ambiguous. For a single state machine it is irrelevant. For a system of a state machine we get a different behavior.
Thank you for a comment to this quite sophisticated issue.