Catch the fastest changes in a PLC

I’m not sure what the right solution here is, or if there is one. Basically I have a state machine in a PLC that is skipping a step somewhere, somehow. For some other reasons, it probably won’t be possible to try and monitor the PLC to find out whats skipping and how, so we’re going to try and catch it in Ignition, but I think that means having a very, very fast scan class. I haven’t been able to find good resources on just how fast a scan class can be - I’d guess the technical min is 1ms, but is that feasible? For how many tags?

Has anyone tried this kind of thing before? Any other suggestions for finding this kind of thing?


You pretty much cannot do this from a SCADA system. PLC logic is too fast, and in my experience, state skips happen within a single scan. To make bullet proof state machines, I lay out the code as follows:

1a) Copy Inputs to Buffers that remain static for the rest of the scan (if not provided by hardware)

  1. Combine inputs into non-state combinations that may be reused. No latches or seal-in branches here.
  2. Timers for debounce of inputs and combination coils as needed. Latches or seal-in branches only for debounce purposes.
  3. Subroutine to evaluate state transitions based only on current state and above conditions. First true rung updates state and returns.
  4. Generate outputs from states.

Point 1a for sure!

As for your current issue, something I’ve done a couple of times is add an incremental counter to each state, which increments once per activation of the state. If your state machine is sequential, ie. S0> S1 > S2 > S3 > Sn > back to S0, or at least if you think the state that is being skipped should always be entered just as many times as the state before and after it, then every counter should be at the same value at any point in time (after a scan).

I just use an add instruction usually, on a INT variable, and increment over itself (var = var + 1) with a one shot. I just let it overflow (make sure adjacent memory is clear) if address based, or have the counter reset itself to 0 if above say 32000.

The actual values don’t matter, the differences between the values should give you an indication of what’s being missed, and these counters can be scanned at normal scan speeds.

I do the same as cmason, set counters. This way as stated you can see any steps skipped or steps duplicated.

Even watching the program live it can be too slow to see whats happening.