113 Siemens Ladder Instructions, One Page Each — and the Sections That Actually Save You Time

When you look up a ladder instruction mid-commissioning, the expensive part is never remembering what the symbol looks like. It's the next two questions: how is this different from the instruction next to it, and what happens if I pick the wrong one.

Learn-LAD's LAD instruction handbook answers exactly those. It's 113 S7-1200/1500 instructions in 13 groups, one page each, with a fixed seven-section structure per page: one-sentence summary, symbol and pins, minimal example, how it works (truth/timing table), typical uses, common pitfalls, related examples. Each page also carries an "try it in TIA" panel: pick an example block, and TiaLink imports it into the TIA Portal project you currently have open — pre-check first, no overwriting of same-named objects by default, no auto-save after import.

It is not a replacement for the TIA help. The help tells you what a pin is; this tells you which instruction to pick, and how it fails.

1. Where people actually get stuck

Everyone learns contacts, coils and timers once. The real problems show up later, and they cluster into four shapes:

1. Neighbours look identical. TON / TOF / TP are all "timers". SCoil and Sr both latch. The failure always happens between two instructions that resemble each other.
2. You know the definition, not the consequence. "ET resets when IN goes to 0" reads as trivia — until you use it as an accumulated run-time counter.
3. Parameter help stops at parameters. TIA help will tell you PT is the preset time. It won't warn you that a one-scan pulse never reaches PT.
4. You understand the page, then rebuild the network by hand — and introduce new mistakes in the rebuild.

So the useful test for any instruction reference is five criteria:

2. Scale: 113 instructions, 13 groups

Three editorial choices say a lot about the intent:

• CoilTON / CoilTOF / CoilTP / CoilTONR get their own pages. Coil-form timers and box-form timers differ in syntax and in where they may be placed; mixing them is a standard commissioning incident.
• OK / NOK / IS_ARRAY / IS_NULL / NOT_NULL are filed under comparison. These aren't comparisons of magnitude; they're validity checks, and you cannot write reusable FBs without them.
• Only four program-control instructions. No attempt to mirror the whole instruction set — just the jump forms ladder actually uses.

Every page header also carries applicable CPUs (S7-1200/1500), the version basis (TIA V19), and aliases — TON is alias-mapped to "on-delay timer / SD", TP to "pulse timer / SP". The alias line matters when you're reading old drawings: the sheet says SD, TIA says TON, same thing.

One implementation detail worth knowing: pin names and directions come from the lad-ir instruction catalogue, and the figures are rendered by lad-render — the same renderer used by the example library, so a handbook figure and an example figure look identical side by side.

3. What one page contains (TON as the example)

Open TON — on-delay timer. Top to bottom, seven sections. The order is itself a reading strategy: usable first, mechanism second, boundary last.

1) One sentence. "TON is an on-delay timer: Q goes to 1 only after IN has been continuously 1 for PT; as soon as IN drops, Q and ET reset." Trigger condition, decision condition, reset condition — drop any one of the three and the instruction gets misused.

2) Symbol and pins.

Plus three metadata lines that decide whether it can live in an FC at all: group: timers, needs an instance, template value: time type.

3) Minimal example. Start held for 5 s, then Motor is set; Start dropping resets Motor immediately. The example uses a static multi-instance Timer inside an FB; in an OB/FC you can use a global IEC timer instance DB instead. The figure notes that # means a block-local variable, and that real projects may use global tags or DB variables.

4) How it works (state table).

Four notes follow, and each one is a pitfall in disguise: IN must be continuous; PT versus ET; ET stops growing once the time is reached; never call the same instance from multiple places.

5) Typical uses. Delay-on start (3–5 s confirmation before energising a motor); debounce / in-position confirmation (drop PT to 200–500 ms and use Q as "signal is stable"); timeout alarm (start timing on the command, alarm if "done" never arrives). That third one adds the premise most people miss: you usually need a NOT Done condition in series, and if Start is a momentary button you must first latch it with SCoil.

6) Common pitfalls.

TON is not TP: TON holds Q until IN drops; TP is a fixed pulse that IN cannot cut short.
TON is not TOF: TOF is off-delay; Q stays 1 for PT after IN drops.
A short pulse never reaches TON: a one-scan pulse never gets to PT.
ET resets: with IN = 0, ET goes back to 0 — don't use it as an accumulator.
Instance conflicts: calling the same instance from multiple networks overwrites the timing.
Missing PT: TIA reports an unused parameter; SCL calls like TON(IN:=...) lose it easily.

Five of the six describe failure shapes, not definitions. That's where the information density of this handbook actually lives — it reads like it was written from observed mistakes, not from a parameter table.

7) Related examples and related instructions. Two graded examples (delayed motor start with pump control; three-motor staggered start/stop), each with a one-line summary and a difficulty tag, plus two lateral links (SCoil, TOF) — "the next thing you will confuse this with".

Bonus: the "try it in TIA" panel. This is the difference from a normal documentation site. A block selector offers variants (TON has minimal example / signal debounce / timeout alarm). Importing then:

• goes through TiaLink into the project you currently have open, with pre-check, no overwrite of same-named objects by default, and no auto-save;
• does not run the block: you still call it from OB1 and wire real variables yourself;
• uses http://localhost:8080 by default, or ?tialink= appended to the page URL;
• accepts the --api-token value if TiaLink was started with one — stored only in the browser's localStorage, never uploaded.

"No overwrite" plus "no auto-save" keeps the risk on the reversible side: the import puts blocks into the project; whether they stay is still your decision.

4. Stress test: the three families people confuse

4.1 The timer trio — TON / TOF / TP

The two pitfalls are mirror images of the same physical fact:

• TON's pitfall is "a short pulse never reaches PT" — so don't use it to catch pulses; use TP or latch an edge.
• TOF's pitfall is "a short pulse is stretched to the full PT" — so don't use it as a pulse filter; it amplifies one scan into the whole preset time.

You only see that pairing when the two pages sit next to each other.

TP also carries an honest footnote: a second rising edge during the pulse usually does not extend it, but confirm the behaviour on your specific CPU/firmware. "I can't guarantee this in a document" is more useful than a confident wrong answer — it tells you to measure.

4.2 Bit logic — Coil / SCoil / RCoil / Sr / Rs

Five ways to write a 1, five different semantics:

Sr's pitfall list is entirely semantic, and every item is a real defect: operand cannot be an Output (TIA does not allow reading outputs — use InOut or Static); don't confuse it with SCoil/RCoil (box versus coil); pick the dominance according to the process; q is an RLO output you can continue in series; and scan order — when a latch bit is written from several places, the result depends on scan order.

That last one is really the thesis of ladder programming: write the same bit from several networks and you don't own a value — you own whatever the last network to reach it wrote.

4.3 Edges — PContact / PBox / PCoil / R_TRIG

Edge instructions are the source of two production classics: the missed pulse and the double count. Eight pages split them by what they watch:

PContact explains the mechanism: the bit is edge memory that stores the operand's previous state, and each edge contact needs its own bit; out = 1 only in the scan where the operand goes 0 → 1, and bit updates at the end of the scan.

Its pitfalls double as a troubleshooting checklist:

• No preceding logic: putting PContact first in a rung violates TIA's edge rules — place an Enable / Not / contact before it.
• Shared edge bits: two PContact sharing one bit overwrite each other and drop pulses.
• Non-retentive edge bits: a bit in Temp is reset on every call — use Static, a global M, or a DB.
• Used as a level: it is high for exactly one scan; if you need persistence, follow it with SCoil or a latch.
• Skipped networks: if a Jump skips the network, the edge isn't recorded — and when the scan returns, the edge may be misinterpreted.

That last one is rarely written down anywhere, yet it's the standard path by which "code that never executes" turns into "an occasional unexpected motion".

5. Three ways to use it

Firefighting (the 30-second rule). One sentence → pin table → pitfalls. Skip the rest. The one-sentence line tells you whether the semantic is the one you want, the pins confirm the wiring, the pitfalls confirm whether your current code is the failure shape.

Studying a group (read the pitfalls as a comparison table). A single page doesn't stick, but read all ten timer pages' pitfalls and you get a map of when not to use which timer; read the eight edge pages and you get a leak checklist. That's more durable than memorising symbols.

Feeding pages to an AI as a checklist. This is the biggest change in how the work is done now. When an AI generates or modifies ladder/SCL, the errors concentrate in four places: wrong timer family, shared edge bits, double coils, instance conflicts — and the pitfalls section of each page is a ready-made checklist. Practically: paste the relevant page (summary + pins + mechanism + pitfalls) as context and ask the model to check the code against it, instead of generating from memory.

Two companion pieces in the same series: 7 lessons from AI PLC programming (the four verification layers — structural validation → TIA compile → cloud simulation → virtual PLC/field — and what each layer does not prove) and the Siemens ladder example library (how 60+ examples are arranged into a practice path). Both are in Chinese.

⚠️ Keep the handbook's own disclaimer in view: instruction pages cover semantics and usage only; they do not replace the TIA help or a process/safety review. Safety-related conclusions require human confirmation.

6. From "found it" to "ran it" in four steps

1. Look it up — confirm semantics and pitfalls on the instruction page.
2. Import — use the "try it in TIA" panel to pull an example block (e.g. TON → timeout alarm) into your open project via TiaLink: pre-check, no overwrite, no auto-save.
3. Wire it — call the block from OB1 and connect real variables. It does not run by itself; this step is the pin comprehension.
4. Prove it — run the timing in cloud simulation, then watch IO behaviour on a virtual PLC. For the layer split, see 7 lessons; for practice without hardware, see Factory I/O + OpenPLC + Modbus TCP.

Compared to pasting a snippet into your project, only step 3 is extra work — and it's what buys you the knowledge of which scan cycle each line runs in. The classic counter-example: during a refactor TP was written as TON; compile reported 0 errors and 0 warnings; pressing the button started nothing.

7. What it deliberately doesn't do

• It doesn't replace the TIA help. Semantics, examples and pitfalls live here; firmware and CPU specifics stay with the official documentation and your own measurements.
• It doesn't replace a process review. Especially for safety (e-stops, safety doors, F-CPUs and F-blocks) — the pages state plainly that safety conclusions require human confirmation.
• The scope is S7-1200/1500 on TIA V19. S7-300/400-era S5 timers (S_ODT and friends) are a different semantic family; don't transplant them.
• Unknown behaviour is labelled unknown. Where a cross-version detail can't be guaranteed (e.g. TP retriggering mid-pulse), the page says "confirm on your CPU" instead of inventing an answer.
• Examples are minimal readable shapes, not production code. No process interlocks, no fault handling — add them yourself and review them.
• Import is not adoption. No overwrite, no auto-save: the decision stays on your side. That's protection and responsibility at the same time.

---

Sources and verification notes

• Handbook index (113 instructions, 13 groups): tia.hubwiz.com/learn-lad/instructions/
• Instruction pages quoted: TON, TOF, TP, CTU, SCoil, Sr, PContact
• Page structure, counts, pin tables, pitfalls and import behaviour were read from the live pages on 2026-10-22. Nothing here was independently re-measured on hardware; instruction semantics remain governed by the TIA help and the process/safety review.
• Cover photo: Pexels #257736 (Pexels License).

Further reading (in Chinese)

• AI × Industrial / PLC guide
• Siemens ladder example library: 60+ importable exercises
• 7 lessons from AI PLC programming, each with an acceptance check
• Ladder to SCL migration guide for TIA Portal
• Pre-commissioning program review with an AI agent
• Practicing PLC without hardware: Factory I/O + OpenPLC

This article was originally published in Chinese on hubwiz.com.