14 — PATTERNS THAT PAY

The handful of structures real machines are built from — and when to use none of them.

Estimated 26 minutes.

A pattern is a shape somebody already paid for

Nothing in this lesson is new syntax. A pattern is an arrangement of the blocks you already have that somebody else found out the hard way — usually on a line that was down at the time. There are maybe seven of them worth naming in automation, and the first one is worth more than the other six put together.

The state machine: one integer, two CASE statements

A sequence is a state and the rules for leaving it. Keep the transitions in one CASE and the entry and exit actions in another, and the whole machine becomes readable in thirty seconds: what state am I in, what will get me out of it, what turned on when I arrived. Entry actions run once on the change rather than every scan, which is what stops a sequence fighting a manual override.

Wire the transitions on a real batch skid

SEQ-201 is a 2000 L batch vessel. The states are already written; the conditions that end them are not. Pick a sensor, drop it on the transition it should finish, then run the sensor profile and see where the batch actually gets to.

The same sequence, both languages

This is the clearest contrast in the whole track. Ladder is better for the interlock that has to be read at 3 a.m.; ST is better for the sequence that has thirty steps.

The state nobody can leave

A commissioning engineer adds a PURGE state to a sequence, writes its entry action, and copies the transition branch from the state above without changing the condition. The machine reaches PURGE and stops. What does the fault look like on the floor?

A PLC fault light — the controller detects the dead state
The sequence sits in PURGE with its outputs on and nothing else happening
The sequence skips PURGE entirely
The scan time climbs until the watchdog trips

Manager and collection: one loop, many machines

When you have several of the same thing, declare an ARRAY of the device block and give one owner the job of calling all of them. The owner does the counting, the summing and the "is anything faulted" question; the devices do the device work. The payoff is that the number of machines becomes data, and data can be changed by a commissioning engineer without a download.

Commission and decommission a conveyor line

Six MDR zone drives, one ARRAY[1..6] OF FB_ZoneDrive, and one FOR loop that owns all of them. Add and remove zones, run the trace, and watch the loop text underneath.

The manager loop in both languages

This is the pattern that makes ST worth learning if you only ever learn one thing from it: the ladder cost grows with the number of machines and the ST cost does not.

Zone 7 arrives

The line is extended by one zone. The program uses ARRAY[1..6] OF FB_ZoneDrive with a FOR loop and a commissioning count. What is the actual change?

A new FB instance, a new call, and a new line in the fault summary
The array bound goes to 7 and the commissioning table gets a row
Nothing — arrays grow at runtime
The FOR loop bound has to be recalculated everywhere it appears

The faceplate pattern: one block per physical device

Every motor, valve and drive on the plant gets its own block instance, and every one of those blocks presents the same status structure and the same command pins. That uniformity is what makes an HMI cheap: one faceplate pop-up, bound three hundred times, instead of three hundred bespoke screens. It is also what makes the alarm list, the runtime report and the lockout logic possible without writing any of them per device.

Strategy: swap the algorithm, keep the pins

On CODESYS or TwinCAT the same thing is an I_Ramp interface and one assignment. Both versions have the same property that matters: the axis code does not know which profile it is running, so a fourth one cannot break the first three.

The fourth ramp profile

A customer wants a fourth ramp profile for a fragile product. The three existing ones sit behind a CASE with one pin layout. What has to be tested before shipping?

All four profiles, because the CASE was edited
The new profile and the selector — the other three blocks were not touched
The whole filler program, since motion is involved
Nothing — adding a branch cannot change existing behaviour

Adapter: the block you were given, not the one you wanted

Some blocks arrive with the hardware — a drive library, a weigh module, a robot interface — and you cannot change them, cannot always read them, and will not always keep them. Wrap each one in a thin house block that speaks engineering units and house pin names, and delegate. The day the drive brand changes, one block changes and the four hundred call sites do not.

Command and queue: a recipe is data

The queue is an array of step structures written by the HMI; the executor is a CASE that never grows unless a genuinely new kind of operation appears. Product 31 costs a data entry, not a download.

Factory: build the instances at compile time

A factory creates instances on demand. On the platforms that support it that is __NEW, and on a machine controller it is almost always the wrong answer: dynamic memory can fail, and it fails at the worst possible moment on the unit that has been running for eight months. Declare the maximum the panel could ever hold, commission what is fitted, and let the download be the record of what exists.

SOLID, in plant language

Five rules from software engineering, none of which need the word "object" to be useful on a skid. Every one of them is really a statement about what has to be retested when something changes.

The scan budget and the safety file

Indirection is not free. A manager loop over two hundred devices runs two hundred times whether or not anything changed, and a dispatch through a contract is a jump the compiler cannot inline — on a 2 ms motion task that is a real number, and the profiler is the only opinion worth listening to. Safety code has a harder rule again: what appears in the safety file has to be readable by an assessor who did not write it, so certified library blocks and plain literal logic win, and anything that decides at runtime which code runs loses.

The 3 a.m. test

The question is never whether a structure is elegant. It is whether the maintenance electrician on nights can find the fault with the line down and a supervisor standing behind them. If the diagnosis needs three jumps through call levels to reach a coil, the structure moved the cost rather than removing it. A single machine that will never be revised, and a plant whose team reads ladder and not ST, are both legitimate reasons to write it flat and write it obvious.

Pattern or overkill?

Four situations off real jobs and four ways to structure them. Every pairing draws the maintenance-cost curve it actually produces over three years. Try at least ten of the sixteen.

The bespoke rig

A systems house is quoting one bespoke test rig: one machine, one customer, no fleet, no repeat order, five weeks to ship. The lead engineer proposes a device contract, an FB array and a manager. What is the right call?

Build it that way — good structure is never wrong
Build it flat and obvious; the change traffic that would repay the structure is not coming
Build the contract but skip the manager, as a compromise
Copy the last rig's program and edit it down

What you learned

The state machine FB — transitions in one CASE, entry and exit actions in another — is the pattern that pays on almost every machine, and a step timeout belongs in it from the start.
A manager plus an ARRAY of device blocks turns "one more machine" into a declaration and a table row instead of an edit.
A faceplate block with one standard status and command surface is what makes an HMI, an alarm list and a runtime report cheap.
Strategy, adapter and command all work in plain IEC without a single METHOD: a shared pin layout, a wrapper block, and a step array with one executor.
Declare instances statically. __NEW exists on some platforms and is almost never the right answer on a machine controller.
SOLID in plant language: one job per block, extend by adding blocks, keep the pin contract honest, keep pin sets narrow, and depend on the device contract rather than the brand.
Structure for change that will actually happen — scan budgets, safety files, one-off rigs and 3 a.m. diagnostics are all good reasons to write it flat.

PATTERNS THAT PAY — done

You can build a batch sequence as a state machine block and read its current state off both the code and the machine.
You can put a fleet of devices behind one manager loop and grow the fleet without touching the loop.
You can name the structure a situation deserves — including the situations where the honest answer is none of them.