1. The state machine could have "auto" and "single-step" transition modes.
The auto mode would be the normal mode.
It is easy enough to add a play and pause input that set and reset a bit that is used for one more condition to be met before going to the next step.
Single step would mean that the state machine would remain in a state even if one or more transitions would be active.
This is easy too. Just clear the play bit on entry to the step or when exiting the last step.
Only when the operator activates a button does the next state become active. In order to manage that nothing harmful can happen (i.e. overheating from remaining too long in a certain state), then each state shal have a flag "allow single step".
So what if play is active and the rest of the conditions are not met?
2. It would be nice if there was a debugging mode, which could be enable/disabled in case there is a tricky problem to locate.
On fault clear the play bit.
Each state, and each transition shall have a text description. When a transition is activated, or a state is activated, the texts are logged to a FIFO log. There should be timestamps in the log.
Good idea. A whole DB can be used as an circular buffer of UDT that are pointers to strings and a value.
The log will then contain entries like:
13:05:00.0000 "Enter INI state"
13:05:10.0000 "Transition T002 triggered"
13:05:10.0000 "State S001 activated"
13:05:10.0200 "Transition T014 triggered"
13:05:10.0200 "State S006 activated"
etc.
Good idea! We do that now. We can even log the variables that are changed and what they are changed too.
SCL/ST handles texts very easily, so it shouldnt be that much work.
Yes but handling strings is not what a PLC should be used for. We store the message number and a value. The software in the laptop or PC formats and displays it.
The trouble with state machines is the splitting of states and transitions means that a running machine can be hard to troubleshoot by just looking into the program online. More debugging aid will be really welcome.
We log the transitions between the states, variable and I/O changes, Profibus and Ethernet communications and Motion commands. We had to do this because you don't want to pause a motion application as it may pause in a dangerous state plus it is hard to instantly start and stop something heavy.
It is much safer to log all the data so that the events leading up to a point can be studied. So how are would be it be to put the time, a message and a value in a UDT and store that in a circular queue of about 1024 entries? Not that hard.
Logging the variables would probably require a function where the time, variable name and new value are logged. I really like the circular queue of 1024 or more UDTs of time, message number and value.
Now how does one read this circular queue up and display it?
I was doing this back in the early 80s. We also had a time out for many states. We displayed a message using a video card to a monitor that said what the state was doing and what it was waiting for to go to the next state. If the state timed out we would flash what the state was waiting for. It pretty much told the electricians which photo eye or limit switch wasn't working. The extra effort required to put in all the diagnostics was paid back with fewer or short tech support calls.
