I would like to introduce this library that I just updated to version 1.0.7
The name chosen, YA_FSM, I have to admit that it is a bit unhappy and does not help much to understand what it was born for at first glance.
This is a library that allows to implement a finite state machine operating mainly in a declarative way, in order to shift the programmer's efforts to the design of a good working automaton rather than to the raw implementation of the necessary C++ code.
It was thinked as a way to reproduce a working model developed according to SFC (Sequential Function Chart) - GRAFCET programming styles on a microcontroller like you could do with modern PLCs for example.
For that reason it rely on concepts like:
steps - the finite states;
transitions - the condition which trig the step change
actions - what to do in each step
I've prepared a wokwi project for almost every example included in library where some simple and common automations are implemented (with different approaches):
I hope this work can be useful for someone and obviously if you have constructive suggestions for improvement or additional features, it will be very welcome.
This looks like a very nice library. Thank you for sharing.
I was wondering whether this is really an implementation of a Petri net though, as these typically have multiple inputs and outputs per node and the state is defined by the distribution of multiple tokens over the nodes. I could not find an example of this, nor could I see any data structure in the source code that implements this at first glance.
By the way, I have some ideas about a (very simple, yet readable) implementation for FSMs that I can share here if you think it will not pollute your thread.
With YA_FSM you could translate the model in this way, but for how it works now, parallel steps it's not implemented.
fsm.AddTransition(P0, P1, T0);
fsm.AddTransition(P1, P2, T1);
fsm.AddTransition(P1, P2, T2);
fsm.AddTransition(P2, P3, T3);
/*
this transition will never be evaluated because also the previous is active
at the same time and then causes the return of the Update() method.
*/
fsm.AddTransition(P2, P0, T3);
fsm.AddTransition(P3, P0, T4);
I think we can live with this problem without worries because it 's enought define a new distinct transition T3_a equivalent to T3 to handle the behavior.
Probably this could be also done directly inside the library, it would be a big improvement.
I have to think about to-do it, but in the meantime thanks for the food for thought!
