miho / vsm

State Machine model + Runtime Execution Engine based on VMF

VSM

State Machine model + Runtime Execution Engine based on VMF

vsm's Issues

Allow multiple executor implementations in one fsm with sub-fsms

Rationale:

The current implementation only allows a single executor implementation in an fsm with multiple nested fsms. This limits the use of different executors since different executor implementations can only be synchronized manually and not via the nested fsm mechanism.

A real use-case:

There are cases where the actual fsm is executed in hardware or external processes but we want to communicate with those entities via the unified event based communication. This is the case for g-code senders that need to communicate via serial port. They switch state on whatever event (possibly hardware and therefore impossible to model in our software). The executor should just communicate with this g-code sender and trigger state-changed events if they report state change, e.g., IDLE->RUNNING or ALARM.

Consequences

Consequences are that the current executor implementation cannot longer rely on implementation details. A executor factory of some sort might be necessary to build up the executor hierarchy.