Geek Answers Handbook

Should a state machine have a "nested" state machine?

You can read this question where I ask about the best architecture for a machine application for a short story, although this is not entirely necessary in order to help me in this matter.

My understanding (especially for implementation) of the Finite State Machine is a little young and maybe a little, but I implement this application as one, and I have a place where I somehow need to have an embedded FSM. Basically, a machine has several high-level states (Cold [aka just started], Homing In, Setup, Ready to Run, Running, Reporting, Reseting), but when the machine is running, it needs to have a small FSM implementation for (Lens loading , edge location, measuring wedge, roundness measurement and completion [may be still there]).

My question is this: should I build the possibility of "nested states" when a state can have a list of sub-states, and the system can enter these sub-states, and these sub-states can return to their parent states? Or should I just turn the FSM implementation into the Running state and save them as two different FSMs? Or do you think I'm doing or think something dumb and should rethink it?

Thoughts, suggestions, criticism and advice are welcome.

+5
source share
4 answers

Nested state machines are a standard concept in UML, so it is not necessarily dumb. More details here .

+6
source

. FSM - .

FSM , FSM . FSM-, . , .

, . (, , ), , , .

FSM.

, "" , FSM. , FSM .

, .

+3

, ( UML FSM) "" FSM .

FSM . , . "" .

+3

, , . Procreation.

ProcreationState

   enum State
{
    SettinNewSearchPosition,
    SearchingForFriend, 
    MovingTowardsFriend,
    EstablishingFriendship,
    Mating
}

In state update mode, I just check what state it is in and acts accordingly. I suggest that this limits the overall ability of this system. I am not so experienced, so I tried it. Any feedback on this approach is appreciated.

0
source

More articles:


All Articles