Anyone written a state machine in Taqoz yet?

bob_g4bby

I used state machines almost exclusively when programming in the test and measurement language LabView - I found them to be very useful in factoring an application into easily read lumps. I've been looking through old Forth magazines for a concise recipe for a state machine. JV Noble had the most to say about them - but before I adapt that to Taqoz - anyone got a neat state machine builder to share?

Christof Eb.

Hi Bob,
You refer to this article?
https://taygeta.com/fsl/docs/551.jvn.fall01/fsm.html
Thanks for the hint! I did not know it.

• I have been using some very simple approach for state machines in the past, without using special words.

(((I am thinking about implementing the classical approach of multitasking with PAUSE for Taqoz. For my YAFFA/Arduino based Forth , which is running on ESP32 I have tried the approach of Matthias Koch, as described here https://wiki.forth-ev.de/lib/exe/fetch.php/vd-archiv:4d2021-01.pdf I hope you could find a way to translate, if you are interested. Of course task switch is relatively slow, because the stacks have to be copied one-by-one, but in many cases this will not be a problem. And on P2 you can always use another core....)))

In media.fth, there is VECTOR: used. Perhaps it might be handy as a starting point for FSM: of the state machine?

Looking forward for your version! :-)
Christof

bob_g4bby

Thanks for the article by Matthias Koch on 'cooperative multitasking' - I'll take a look and see if we could add it to Taqoz or whether it would require a Taqoz upissue.

I like the classical round-robin multitasker with PAUSE as the task switch - I've used it successfully in Flashforth / PIC. As an alternative approach that builds on top of Taqoz, I am thinking of using Mini-OOF to create a 'state machine' class, that can (a) SMOPEN - initialise stuff (b) step SMSTEP to the next state (c) SMCLOSE - clean up stuff and go idle. It would be used on the same lines as my Timer class e.g.

    SM1 SMOPEN
    SM2 SMOPEN
    SM3 SMOPEN          --- all state machines are initialised now
    BEGIN
        SM1 SMSTEP
        SM2 SMSTEP
        SM3 SMSTEP      --- each state machine is stepped by one state
    KEY UNTIL
    SM1 SMCLOSE         
    SM2 SMCLOSE
    SM3 SMCLOSE         --- all state machines have cleaned up any resources used and gone idle

A cog or cogs could run as many of these state machines as necessary, because it's OOF code and each instance has it's own set of variables. Where a state machine is required with more variables, then a new class is created from the 'state machine' class that includes the new variables and quite probably more methods to control it. All the basic 'state machine' behaviour is inherited of course.

I must admit I found JV Nobles article a bit hard to follow - i switched to an article 'Simple State Machines' by Jenny Brien in the May 2004 copy of Forthwrite magazine

Such a scheme imposes restrictions - e.g. only one data stack is being used in any one cog. Each step in a state machine has to leave the data stack at the same depth as it started with. Passing data from one state to another has to be by other means. This isn't a new situation - passing data from one cog to another has the same issues.

VECTOR: does look useful and also maybe REVECTOR

ErNa

Not having written more then ten lines in TAQOZ it should have be enough to write a state machine. But it isn't.
But this is definitely a way want to go.
I think, the best way to create such a machine is by starting with a simple example. And it fits that I just created a little controller to run a hot wire cutter. I'm using one of my many P1's, for relais, two motors and three switches.

The task is quit simple: start the machine, wait for an event, make the state transition. A single cog, no parallel processing, no communication with a terminal etc.

As soon as we become acquainted reading and writing FORTH code (something I still miss after so many years) we can use parallel objects, modify the state machine on the fly, communicate with other processes, written in whatever language, etc..

So here is what the program does:

There is a hot wire mounted to an axis. On pressing start, the wire heats up and advances radially to the center, when touching a limit switch, a table starts rotating, when one round is completed, the table stop, the wire starts to retract.

There also is a service mode that is entered, when the axis limit switch LS_A is pushed while in idle mode. Every next LS_A push advances to the next action, a push of the start button toggles the signal. The service routine is left, when the limit switch of the table is pressed.

Now I'll look into the state machine software and the documents linked..