State tracing is very similar to sign posts. You could also call it sign posts applied to Event-Action programming (a.k.a Finite State Machines or FSM).

This is not the place to teach you about FSMs. Suffice to say they are the most powerful way known to man of programming control sequences that can take into account the past history of the system. One easy way to get into this technology is with our Tabula programming tool.

If you understand FSMs, you will understand the concept of adding a serial debugging signpost on every state entry, which gets execute just one upon entering the state. You could also add signposts to event code or transition code, but that is more cumbersome. Generally it is quite possible to identify a bug by tracking state entries.

One advantage of numbering states, as distinct from (or maybe in addition to) naming them, is that the signpost display can take up less space on the terminal screen. Tabula supports this idea, in that states (table columns) are always numbered.

Multiple state machines

If I have multiple state machines running under MultiTrack, and cannot debug one in isolation from others, I enclose the state numbers in different types of brackets, so that (3) and [3] are states in different state machines.

Multiple instances of one state machine

If you have multiple instances of a particular state machine in several MultiTrack tasks, it becomes a little more interesting. You then need to generate signposts that includes the task’s value of J. as well as the state number. There are two ways to discover a task’s J value, using either BranchJ or LaunchTaskX. Both methods require some special initialisation code, plus an array of jndexed bytes to hold the state numbers