Learning Objectives

By the end of this lesson, the technician will be able to:

• Objective 1 (Cognitive/Understanding): Read the timer (TON, TOF, RTO) and counter (CTU, CTD) instructions — their preset/accumulated structure and their status bits (EN, TT, DN) — and predict their behavior from a monitored rung.
• Objective 2 (Cognitive/Understanding): Interpret comparison (EQU, NEQ, LES, GRT, LIM) and math (ADD, SUB, MUL, DIV, including scaling) instructions well enough to follow how analog values become decisions.
• Objective 3 (Diagnostic/Analytical): Diagnose timing- and counting-related machine misbehavior — premature faults, missed counts, stuck sequences — by reading preset vs. accumulated values live, without modifying the program.

Field Scenario

The Pump That Faulted Every Morning — at Exactly the Same Second: A transfer pump faults on "LOW FLOW" every morning during first start, then runs perfectly all day after a reset. The night crew has started "double-starting" it as a ritual. The work order suggests replacing the flow switch.

In monitor mode, you find the fault rung: the pump run command starts a TON (on-delay timer) with a preset of 3.0 seconds; if the timer's DN (done) bit comes up while the flow-proven input is still false, the fault latches. The logic is sound: start the pump, give the line 3 seconds to establish flow, fault if it never proves.

You watch a morning start with the timer on screen. The flow switch makes at 3.4 seconds — every time. Then an afternoon start: flow proves at 1.9 seconds. The flow switch isn't failing; the process changed. Maintenance records show the line was repiped two months ago with a longer run and a check valve — a cold, empty line now takes ~3.5 seconds to fill before flow can prove. The 3.0-second allowance was calibrated to plumbing that no longer exists.

The finding goes to the controls engineer with data: preset 3.0 s, measured cold-fill flow-proof time 3.4 s, warm 1.9 s. Engineering changes the preset to 5.0 s through the site's change process — the technician's job was the diagnosis, and the diagnosis was a number. No flow switch was harmed in the making of this repair.

Concept Overview

Bit logic (Lesson 7.4) decides whether; these instructions decide when, how many, and how much. They share one anatomy: a data structure holding a Preset (PRE) — the target — and an Accumulator (ACC) — the live running value — plus status bits the rest of the program watches.

Timers

• TON — On-Delay (the workhorse): rung goes true → ACC climbs from 0 toward PRE. EN (enabled) is on while the rung is true; TT (timing) while ACC is climbing; DN (done) sets when ACC reaches PRE. Rung goes false → everything resets to zero. Use: "wait 3 seconds after start before checking flow."
• TOF — Off-Delay: the mirror — the timer measures after the rung goes false; DN stays on through the delay. Use: "keep the cooling fan running 60 seconds after the weld head stops."
• RTO — Retentive Timer: like TON, but ACC holds its value when the rung goes false and resumes climbing when it goes true again; only an explicit RES (reset) instruction clears it. Use: accumulating total run-hours toward a PM trigger. Field consequence: an RTO that "mysteriously remembers" through power cycles is behaving correctly — find its RES rung to understand when it clears.
• Time base matters: presets count in a configured base (1.0 s, 0.01 s, or milliseconds by platform). A preset of "500" is 500 of something — read the time base before concluding a delay is wrong.

Counters

• CTU — Count Up: each false-to-true transition of its rung increments ACC; DN sets when ACC ≥ PRE. The transition detail is everything: a rung held true counts once, not continuously.
• CTD — Count Down decrements on each transition; CTU/CTD pairs on the same address track in/out flows (parts entering vs. leaving a buffer).
• RES clears the counter. Counters are retentive by nature — they hold through power cycles until reset, by design.
• The classic counting pathologies: double counts (sensor chatter/flicker on a marginal target — Lesson 6.2's excess-gain problem arriving in software) and missed counts (pulse shorter than the scan time — Lesson 7.1; the cure is hardware high-speed counting, not sensor swapping).

Comparison Instructions — Where Analog Becomes Decision

EQU (=), NEQ (≠), LES (<), GRT (>), GEQ/LEQ, and LIM (true when a value is inside/outside a band) sit in rungs like contacts: GRT(Tank_Temp, 180) → alarm. Two field rules:

• EQU on analog/floating-point values is a design smell — a live analog value is essentially never exactly equal to a constant; well-built programs compare with bands (LIM) or thresholds. An "equal" test that never fires may be working exactly as (badly) written.
• Comparison setpoints are often HMI-adjustable tags, not constants — when a comparison misbehaves, read the current setpoint value first; an operator may have keyed 1800 where 180 belonged.

Math and Scaling — the Bridge from Counts to Units

ADD/SUB/MUL/DIV (and platform scaling instructions like SCL/SCP or CPT compute blocks) transform raw values into engineering units. The one every technician must recognize is the analog scaling pattern: raw A/D counts (Lesson 6.1) → scaled units via the linear map (raw − raw_min) × (EU_span ÷ raw_span) + EU_min. When an HMI value is exactly proportional-but-wrong, the error lives here (the double-square-root scenario of Lesson 6.6 is this lesson's math gone wrong). Division by a tag that can reach zero produces program faults with timestamps — a fault table entry pointing at a math instruction usually means a sensor or entry feeding it went to zero.

How the Principle Works: Reading PRE vs. ACC Live — the Diagnostic Goldmine

Monitor mode shows every timer and counter's PRE, ACC, and status bits in real time. The comparisons between them answer most timing/counting service calls:

• ACC climbing but machine "stuck": the machine isn't stuck — it's waiting. Find what the DN bit releases; the real question becomes "why is this delay so long?" (time base? preset changed?).
• ACC frozen at 0 with the rung true-looking: the rung isn't actually true — walk it per Lesson 7.4; some condition upstream is dropping out faster than the eye sees (an intermittent input chattering the timer's reset is invisible until you watch ACC repeatedly restart).
• ACC resets partway repeatedly: the enabling rung is bouncing — chase the flickering input (sensor marginal, wiring intermittent), not the timer.
• Counter ACC ahead of physical count: double-counting — watch the input channel LED for flicker as parts pass (Lesson 6.2 alignment/excess gain).
• Counter ACC behind physical count: missed transitions — pulse width vs. scan time; the fix is hardware (high-speed counter input) or sensing geometry, never "count harder."
• Sequence stalls at one step: sequences are timers, counters, and comparisons chained through interlock flags; find the step's advance condition (usually one rung) and identify which instruction in it is dark — Lesson 7.4's method, now with PRE/ACC literacy.

The boundary that cannot be crossed: presets and setpoints visible in monitor mode are also editable in monitor mode on most platforms. Reading them is diagnosis; changing them is a controlled program change — engineering review, site change process, documentation (and on anything safety-related, SME/engineering only). The Field Scenario technician measured, documented, and escalated; the preset change happened through the change process. That is the lane (formalized further in Lesson 7.6).

Instruction Reference Matrix

Field Application Checklist: Diagnosing a Timing or Counting Complaint

Boundaries — restated because this lesson lives next to them: monitor/read-only; no preset, setpoint, or logic changes; no forces; changes go through engineering and the site change process. LOTO and electrical rules per Module 1 for any physical verification.

1. Quantify the complaint in time or count: "faults every morning" becomes "flow proves at 3.4 s vs. a 3.0 s allowance" only if you measure. Stopwatch the physical event; capture HMI/fault timestamps.
2. Locate the relevant timer/counter via the fault message, HMI tag, or cross-reference from the output involved (Lesson 7.4 tracing).
3. Read the structure live: PRE, ACC, time base, and status bits through several machine cycles. Record actual ACC values at the moments that matter (when flow proves, when the part passes, when the fault latches).
4. Classify using Section 4's signatures: waiting vs. bouncing vs. miscounting vs. mis-scaled. Each signature points at a different physical chase (input chatter → Lesson 6.2/7.3 chain; scan-time miss → hardware counting; process slower than allowance → engineering data package).
5. Verify the physical side before blaming values: a "wrong" count or time is usually a true report of a wrong physical condition — the Field Scenario's timer was honestly reporting a slower pipe.
6. Check the human inputs: HMI-adjustable presets and setpoints — current value vs. the documented/spec value. Unexplained differences go in the report (and the site change process gets a gap flagged: adjustable values without change control drift forever).
7. Package the diagnosis as data: instruction, address/tag, PRE/time base, measured ACC behavior, physical measurements, and the recommended change — delivered to engineering. The technician's deliverable is the case, not the keystroke.
8. After any authorized change is made (by the authorized party), verify across the conditions that showed the problem — the morning cold start, not just a warm afternoon test — and document closure with the same numbers that opened it.

Knowledge Check

Source List

• Rockwell Automation / Allen-Bradley — Logix5000 General Instructions Reference Manual (TON/TOF/RTO, CTU/CTD, comparison and compute instructions)
• Siemens — STEP 7 instruction references (IEC timers/counters: TON/TOF/TP, CTU/CTD)
• IEC 61131-3 — Programmable Controllers: Programming Languages (standard timer/counter function blocks)
• Frank Petruzella, Programmable Logic Controllers (McGraw-Hill) — timer, counter, and data-handling chapters
• ISA Certified Control Systems Technician (CCST) Program — PLC data and instruction fundamentals