LADX
Start free
← Resources
Instructions·6 min read·

Sequencer instructions, and the state machine that replaced them

SQO, SQI and SQL, what they were for, why they are rare in new code, and what to write instead.

Short answer

SQO steps through a file of output patterns, writing one row to a destination each time it is triggered, which drives a fixed repeating sequence of outputs. SQI compares inputs against a file of expected patterns to advance. They were memory efficient on early controllers and are hard to read and hard to modify, so new code usually implements the same behaviour as an explicit state machine.

Reading an I/O addressSIEMENS%Iarea0byte.0bitALLEN-BRADLEY (SLC)Ifile:1slot/0bitSame terminal. Different vocabulary.Siemens addresses memory areas;Allen-Bradley addressed files and slots.ControlLogix dropped both for tags,which is why migration loses the map.

Open a maintained SLC 500 or PLC-5 program and there is a reasonable chance of finding a sequencer at the heart of it, and a reasonable chance that nobody currently at the site knows how it works.

What they do

SQO, sequencer output. A file of words, each word a pattern of output bits. Each time the instruction is triggered it advances one position and writes that word to a destination, through a mask that protects bits it should not touch.

SQI, sequencer input. The mirror image. Compares an input word against a row of expected values and goes true when they match.

SQL, sequencer load. Records the current input into the file, which was used to teach a sequence by operating the machine by hand.

Used together, SQO drives the outputs for the current step and SQI confirms the feedback matches before the step advances. That pairing is the whole idiom.

Why they existed

Memory. A PLC-5 with a few kilobytes of user memory could not afford a rung per step for a forty step sequence, and a table of forty words with one instruction reading it was dramatically smaller.

It was a genuinely good engineering answer to a real constraint that has not existed since.

Why they are hard to live with

The logic is in the data. The rungs show a sequencer instruction and a file address. The actual behaviour is in a table of hexadecimal words, which is not visible on the ladder and does not appear in a printout.

Changing it means recalculating patterns. Adding an output to step twelve means editing a bit in a word, and getting the bit position right by counting.

Version control cannot see it. A diff shows that a data table changed. It cannot show that step twelve now also opens valve four.

Nobody can read it at three in the morning. Which is when it matters.

The replacement

An explicit state machine, and it is longer and better.

  • An integer holding the step number.
  • One rung per step driving that step's outputs, with the step number as the condition.
  • One rung per transition, with the condition that advances it and the new step number.

It takes more screen space. It is also greppable, diffable, readable by somebody who has never seen the machine, and modifiable without arithmetic.

The one property worth preserving from the sequencer idiom: a step should advance on confirmed feedback, not on a timer. A step that advances because two seconds elapsed is a step that advances whether or not the valve moved.

Migrating one

If you are converting a legacy program, the sequencer is the part to do by hand rather than mechanically.

Print the data table. Write out what each step does and what makes it advance, in words, and get it confirmed by somebody who runs the machine. Then write the state machine from the description.

A mechanical translation of a sequencer produces something as unreadable as the original with none of the memory saving.

Common questions

Are sequencer instructions still used?
In maintained legacy code, constantly. In new code, rarely. They were designed when memory was scarce enough that a table of bit patterns beat explicit rungs, and that constraint has not applied for twenty years.
What is the difference between SQO and SQI?
SQO writes: it takes a row from a file and puts it on a destination word, driving outputs. SQI reads: it compares an input word against a row and reports whether they match, which is used to decide whether the sequence may advance. Together they make a step complete only when the expected feedback arrives.
What should I write instead?
An integer step number, one rung per step for its outputs, and one rung per transition with an explicit condition. Longer on screen and immediately readable, diffable in version control, and modifiable without recalculating a table of bit patterns.

Keep reading