What Is Instruction List?

Back to Blog

How Instruction List Works

Instruction list works on an accumulator model, much like assembly language. Each line contains an operator and an operand: a LD (load) instruction places a value in the accumulator, an operation such as AND or ADD combines the accumulator with an operand, and an ST (store) instruction writes the result out. Programs are read top to bottom, one terse instruction at a time.

This low-level style makes IL extremely compact and, on older hardware, very efficient - it maps closely to what the processor actually does. But that same terseness makes it hard to read and easy to get wrong. A logic scheme that is obvious in ladder or function block diagram becomes a wall of cryptic mnemonics in IL, which is a large part of why the industry moved away from it.

Why IL Is Being Retired

The IEC 61131-3 committee removed instruction list from the third edition of the standard, effectively deprecating it in favor of the more readable languages - ladder diagram, function block diagram, structured text, and sequential function chart. Modern tools and modern hardware no longer need the efficiency IL once offered, and maintainability now matters more than saving a few processor cycles.

Despite that, IL has not vanished. It survives in older installations and was closely associated with the Statement List (STL) language in the Siemens world. Engineers maintaining legacy compressor packages, metering skids, or aging plant controllers still run into it, which is why understanding the basics remains useful. Whatever language the logic uses, the controller exposes its data as tags; a SCADA platform like Merobix reads those tags over the PLC's native protocol without needing to interpret the IL itself.

A Worked Example: The Seal-In Circuit

The classic motor start/stop seal-in shows the language's flavor in four lines. In IEC instruction list it reads: LD Start, then OR Motor, then ANDN Stop, then ST Motor. Line by line: LD Start loads the start pushbutton's state into the accumulator (the standard calls it the current result); OR Motor combines it with the motor's own output, which is the seal-in that keeps the motor running after the button is released; ANDN Stop ANDs in the inverted stop button so a pressed stop kills the result; ST Motor writes the final value to the output.

The same logic in ladder logic is one rung you can read at a glance: a start contact in parallel with the motor contact, in series with a normally closed stop contact, driving the coil. The IL version demands that you mentally carry the accumulator's state from line to line - nothing on line three means anything without lines one and two - and that hidden running state is exactly why dense IL is hard to review and easy to break.

Pitfalls When Reading Legacy IL

Real legacy code is worse than the textbook version. Watch for: negation modifiers hiding in mnemonics, where ANDN and AND differ by one character and reverse the logic; parentheses that defer an operation until the matching close, so the actual evaluation order is not the reading order; and jump instructions that route execution around blocks based on the accumulator, turning a linear listing into spaghetti where only some lines execute on some scans.

Dialects add another layer. The Siemens STL world uses its own mnemonics and features that do not map one-to-one onto the IEC language, so an engineer fluent in one can still misread the other. And because comments were expensive on the terminals this code was written on, assume the documentation lives in a retired engineer's head - verify behavior from the running process, not from the listing alone.

Translating IL to a Modern Language

Migrate intent, not lines. Start by documenting what each block actually does from the process's point of view, not the accumulator's, and capture the controller's real I/O behavior as your reference. Boolean interlock-style sequences translate naturally into ladder rungs; arithmetic, sequencing, and state machines translate better into structured text. Keep a variable mapping table as you go, because legacy IL loves reusing scratch memory for unrelated jobs.

Verify the translation against recorded scenarios rather than by inspection: same inputs, same outputs, across the cases that matter, including power-up state and fault paths. Watch specifically for scan-order dependencies and edge-triggered behavior, which can change subtly after restructuring, and treat any block whose outputs depend on jump-skipped code as suspect until it is exercised on the bench. For choosing the target language block by block, the comparison of the five IEC 61131-3 languages is a useful frame.

Frequently Asked Questions