PLC Timer Types: TON, TOF, TP and Retentive Timers

PLC timers are scan-executed instructions, not universal wall-clock objects. A TON normally delays an output after an enable becomes true, a TOF delays an output after the enable becomes false, and a retentive timer preserves accumulated time until a defined reset—but exact status bits, reset behavior, time representation and power-cycle retention differ by PLC family.

The examples below are training patterns. Translate them with the exact controller's instruction reference, test the boundary conditions, and keep ordinary timer logic out of safety functions unless it is part of a certified and validated safety application.

Direct answer: the main PLC timer types are TON, TOF, TP and accumulative or retentive timers

Choose the timer from the required transition, not from a familiar mnemonic. TON delays a true output after its input becomes true. TOF makes its output true with the input, then delays the output turning false after the input falls. TP produces a pulse of a defined duration after its triggering transition. A retentive or accumulative timer keeps elapsed progress across input interruptions until a separate reset. These are the main behavioral families, but vendors expose different names, data structures, time bases, reset interfaces and retention guarantees.

Required behavior	Common family	Output behavior	Interruption behavior	First boundary test
input must remain true for a duration	TON / on-delay	Q becomes true after preset	ordinary IEC-style TON resets when input goes false	drop input one task before completion
output must remain true briefly after input falls	TOF / off-delay	Q is true with input and falls after off-delay	reassertion during timing is vendor-defined in detail	reassert input halfway through off-delay
create one fixed-duration pulse	TP / pulse timer	Q becomes true for a preset interval	retrigger and input-change behavior must be checked	trigger again while Q is already true
add several enabled intervals	TONR, RTO, accumulative timer	Q becomes true after accumulated time reaches preset	elapsed value pauses/holds until explicit reset	interrupt twice, resume, then reset
repeat an event periodically	timer plus explicit state/edge logic or a vendor block	one-cycle or fixed pulse per period	restart and drift depend on implementation	measure ten periods, not only the first
measure very long duration or wall-clock schedule	long-duration timer, runtime totalizer or RTC/calendar logic	application-specific	rollover, clock correction and persistence dominate	power cycle, date change and maximum range
detect task/scan overrun	watchdog/task monitor, not an ordinary process delay	controller fault/status response	CPU/OS-specific	controlled overrun only in an approved test system

“Cyclic timer,” “interval timer,” “delay timer” and “watchdog timer” are not universal IEC instruction names. They describe requirements or vendor features. Resolve each one to an exact library instruction and tested state model before writing production logic.

Reproducible timer boundary test

Use one output bit and log the enable, output, elapsed/accumulated value, reset and controller mode at each scan boundary.

Test	Input sequence	What to verify
Below preset	Enable for PT − one task interval	Output remains false
At/after preset	Hold enable through the boundary	Exact scan in which output becomes true
Drop enable	Remove input while timing	TON reset and TOF behavior match the manual
Re-enable	Toggle after a partial interval	Non-retentive versus retentive accumulation
Explicit reset	Assert reset while disabled and while enabled	Accumulator and status-bit behavior
Skipped instruction	Bypass the routine for several scans	Whether values freeze, reset or continue
STOP/RUN	Change controller mode in a lab	Restart state and retained data
Power cycle	Cycle power only on approved test hardware	Actual retention, first-scan and output state

Run the same timer matrix in the browser, export the results, and compare them with the target controller. Simulation is for logic practice; it does not prove hardware timing or safety response.

Table of Contents

1. Understanding PLC Timer Fundamentals
2. Types of PLC Timers
3. Timer Programming Syntax
4. 10 Practical PLC Timer Examples
5. Advanced Timer Programming Techniques
6. Common Timer Programming Mistakes
7. Timer Troubleshooting Guide
8. Best Practices for Timer Programming
9. Frequently Asked Questions

Which PLC timer program example should you start with?

Start with a TON on-delay command/feedback timeout, because it teaches the most transferable timer contract: a request creates a command, independent feedback must arrive before a preset, and expiry removes the command and records a fault. Test just below, at and above the preset; drop the enable during timing; restore it; skip the timer call deliberately in a lab; and repeat the startup/restart case. That evidence is more useful than a blinking lamp that proves only the timer can toggle a bit.

Choose the example from required behavior:

Program requirement	Timer pattern	Worked owner in this guide	Essential negative test
delay a second conveyor after the first starts	TON with independent downstream permissive/feedback	conveyor start delay	first conveyor stops before delay completes
fault when motor feedback does not arrive	TON measuring command without feedback	motor startup monitoring	feedback arrives one task after preset
run a mixer for a bounded phase	state plus TON, not a free-floating timer bit	batch mixing phase	stop/abort during mix and restart policy
prevent immediate restart after a stop	TOF or explicit inhibit state according to requirement	restart inhibit	new request while inhibit remains active
accumulate equipment run time	retentive/accumulative timer or runtime totalizer	pump runtime tracking	interruption, explicit reset and power cycle
monitor a sequence deadline	state-owned TON with first-out diagnosis	cycle-time monitoring	sequence step never completes

The mnemonic alone is not portable. For every timer, write the trigger, preset owner and unit, completion meaning, interruption behavior, reset rule, skipped-call behavior, controller STOP/RUN and power-cycle expectation. Then translate the pattern to the exact Siemens, Rockwell, CODESYS, Omron, Schneider, Mitsubishi or other instruction documented for the target.

The planned /guides/plc-timer-program-example route redirects to this page because the canonical already owns ten timer programs, current vendor syntax, scan-boundary tests, troubleshooting and limitations—and already ranks in the live example cohort. A second page would compete with the existing winner.

The former /plc-guides/feature/timers listing also redirects here. Saved research measured plc timers at 930 global searches with KD 24 and found the same timer-type/programming cohort already served by this established owner. Keeping the comparison, examples, tests, FAQs and primary sources on one canonical avoids splitting broad timer relevance across a thin generated listing. Vendor-specific implementations such as the Mitsubishi PLC timer guide and Omron PLC timer guide remain separate because their device, operand, time-base and migration tasks are materially different.

Understanding PLC Timer Fundamentals

PLC timers control scan-based time conditions. Most expose some form of instruction instance, preset and elapsed or accumulated value, although names and accessible members vary:

Timer Address: A unique identifier (such as T4:0 in Allen-Bradley or T1 in Siemens) that distinguishes one timer from another in your program.

Preset Value: The target time duration that determines when the timer will activate its output. This value is typically expressed in seconds, milliseconds, or time base units depending on your PLC platform.

Elapsed or Accumulated Value: The time tracked by the instruction. Whether it resets, freezes or is retained depends on timer type, execution and platform.

Understanding these components is crucial for effective timer programming. The timer's operation depends on the relationship between the preset value and accumulated value, with different timer types responding differently when these values interact.

Types of PLC Timers

Most IEC-style libraries begin with TON, TOF and TP. Many platforms add an accumulative/retentive form, long-duration type, vendor-specific resettable variants or numbered legacy timers. The names are useful for selection, but the actual instruction reference controls the behavior.

Timer On-Delay (TON)

The Timer On-Delay is the most commonly used timer in industrial automation. When the timer's input condition becomes true, the timer begins counting from zero toward the preset value. The timer's output activates only after the accumulated value reaches the preset value.

Key Characteristics:

• Provides a delay between input activation and output activation
• Maintains output state as long as input remains true after timing out
• Resets immediately when input condition becomes false
• Useful for equipment start-up delays and process permissive verification

Typical Applications:

• Motor start delays in sequential operations
• Process settling or restart-inhibit periods after equipment stops
• Process settling time before measurement
• Equipment warm-up periods

Timer Off-Delay (TOF)

The Timer Off-Delay provides the opposite functionality of TON. When the input condition transitions from true to false, the timer begins counting. The output remains active during the timing period and deactivates only after the preset time expires.

Key Characteristics:

• Output activates immediately when input becomes true
• Provides delay between input deactivation and output deactivation
• Timer counts only when input is false
• Useful for process run-on or indication where delayed deactivation is acceptable

Typical Applications:

• Fan run-on timers for cooling after equipment shutdown
• Conveyor belt overrun to clear products
• Ventilation or process run-on where a risk assessment permits delayed deactivation
• Equipment coast-down protection

Retentive Timer (RTO)

The Retentive Timer maintains its accumulated value even when the input condition becomes false. This timer continues counting from where it left off when the input is reactivated, making it perfect for applications requiring cumulative timing.

Key Characteristics:

• Accumulates time across multiple input cycles
• Requires separate reset condition to clear accumulated value
• Power-cycle retention depends on the controller, memory configuration and instruction
• Ideal for maintenance scheduling and process totalizing

Typical Applications:

• Equipment run-time tracking for maintenance scheduling
• Process step timing that can be interrupted
• Batch process timing with manual intervention
• Cumulative operation time monitoring

Pulse Timer (TP)

A TP starts a fixed-duration output pulse on its documented triggering transition. Current CODESYS Standard documentation describes a rising edge at IN starting the pulse and setting Q true for PT. That does not make every vendor's pulse instruction retriggerable, extendable or cancellable in the same way.

Use a pulse timer for a bounded request pulse, indicator flash or test stimulus only after these cases are defined:

• input remains true longer than the preset;
• input falls while the pulse is active;
• another rising edge arrives during the pulse;
• preset changes while the pulse is active;
• the instruction is skipped or its task is disabled; and
• the controller changes mode or restarts.

For a physical valve, reject actuator or solenoid, the timer output is still only an ordinary command request. Recheck current permissives and validate the real electrical/mechanical response independently.

Accumulative, retentive and runtime-totalizing timers

“Retentive” has at least two layers. First, the instruction can retain elapsed progress when its enable becomes false. Second, the controller may or may not preserve that state across stop/run changes, downloads or power loss. Do not turn the first behavior into a promise about the second.

Rockwell Logix exposes RTO in ladder and resettable RTOR in function block/Structured Text. Siemens S7-1200/1500 exposes TONR, whose accumulated time pauses when IN is false and clears through R. Omron NJ/NX lists AccumulationTimer. Traditional Omron families use their own accumulative timer instructions. These can express similar requirements but are not source-compatible.

For maintenance runtime measured over months or years, a short process timer is often the wrong data model. Define rollover, persistent storage, write endurance, clock/task basis, restart reconciliation and evidence after a power interruption. A runtime totalizer and a five-second pause-and-resume timer deserve separate requirements.

Cyclic, interval, long-duration, calendar and watchdog timing

These labels need translation before implementation:

Informal label	Safer implementation question	Common failure
cyclic timer	should a state machine retrigger a TON, or should a vendor periodic block create a one-scan event?	self-reset logic creates scan-dependent pulse width or drift
interval timer	is the period measured start-to-start or completion-to-start?	accumulated execution time shifts the schedule
long timer	does the target provide a wider type/instruction, or should elapsed time be totalized?	preset or accumulator rollover
calendar timer	should the design compare a validated real-time clock and timezone schedule?	DST, manual clock adjustment or invalid time source
watchdog timer	is this CPU/task supervision, communications freshness or a process timeout?	one vague “watchdog” bit hides which layer failed
debounce timer	must an input remain stable for a duration in one or both directions?	filtering changes process semantics or masks a wiring defect

The established PLC scan-cycle and watchdog guide owns CPU/task overrun intent. Timer-type selection here covers process logic and the boundary to watchdog supervision without duplicating that specialist owner.

Timer Programming Syntax

Timer programming syntax varies between PLC manufacturers, but the fundamental concepts remain consistent. Understanding the syntax differences helps you adapt timer logic across different platforms.

Legacy Allen-Bradley SLC/MicroLogix timer syntax

The T4:0 form below is a legacy SLC/MicroLogix example, not current Logix tag syntax:

TON
Timer: T4:0
Time Base: 1.0
Preset: 100
Accum: 0

Address Components:

• T4:0 represents Timer file 4, element 0
• Time Base defines the timing resolution (0.01s or 1.0s)
• Preset sets the target timing value
• Accum shows current accumulated time

Status Bits:

• T4:0/DN (Done Bit): Activates when Accum ≥ Preset
• T4:0/TT (Timer Timing Bit): Active while timer is counting
• T4:0/EN (Enable Bit): Active when timer input is true

Siemens IEC timer call

Siemens IEC timer instances use parameters such as IN, PT, Q and ET. Create the instance in the manner required by the selected CPU and language:

TON T1
IN := Start_Button
PT := T#5s
Q => Output_Coil
ET => Display_Time

Parameter Definitions:

• IN: Input condition for timer activation
• PT: Preset Time using TIME format (T#5s = 5 seconds)
• Q: Timer output status
• ET: Elapsed Time value

Universal Timer Logic

Regardless of manufacturer, timer programming follows consistent logical principles. Here's a universal approach to timer implementation:

1. Define Timer Purpose: Determine whether you need ON-delay, OFF-delay, or retentive timing
2. Set Preset Value: Calculate required timing based on process requirements
3. Identify Input Conditions: Define what triggers timer operation
4. Program Output Actions: Specify what happens when timer activates
5. Include Reset Logic: Plan how and when the timer should reset

10 Practical PLC Timer Examples

These training examples illustrate common timing patterns. They are pseudocode, not complete controller projects: add mode handling, output arbitration, fault response and device-specific syntax before testing on equipment.

Example 1: Conveyor Belt Start Delay

Application: Prevent multiple conveyors from starting simultaneously to avoid power surge.

Requirements:

• Conveyor A starts immediately when START button is pressed
• Conveyor B starts 3 seconds after Conveyor A
• Conveyor C starts 3 seconds after Conveyor B

Timer Logic:

Rung 1: Conveyor A Control
|--[START_BUTTON]--[STOP_BUTTON/]--+---(CONVEYOR_A_RUN)---
                                   |
                                   +---(TON_DELAY_B)-----
                                      Timer: T4:0
                                      Preset: 30 (3.0 sec)

Rung 2: Conveyor B Control  
|--[T4:0/DN]--[STOP_BUTTON/]---------(CONVEYOR_B_RUN)-----
                |
                +----------------------(TON_DELAY_C)-----
                                      Timer: T4:1
                                      Preset: 30 (3.0 sec)

Rung 3: Conveyor C Control
|--[T4:1/DN]--[STOP_BUTTON/]---------(CONVEYOR_C_RUN)-----

Key Learning Points:

• Cascaded timers create sequential delays
• Timer done bits serve as input conditions for subsequent operations
• A separately engineered stop/safety path must remain dominant over this process sequence

Example 2: Motor Soft Start with Monitoring

Application: Gradually start large motors to reduce electrical stress and monitor start-up success.

Requirements:

• Press START button to initiate motor start sequence
• Activate starter contactors in 2-second intervals
• Monitor successful start within 10 seconds
• Provide alarm if motor fails to start properly

Timer Logic:

Rung 1: Start Sequence Initiation
|--[START_BUTTON]--[MOTOR_RUNNING/]--[ALARM/]---(START_SEQUENCE)---
                   |
                   +--------------------------------(TON_MAIN_DELAY)---
                                                   Timer: T4:2
                                                   Preset: 100 (10.0 sec)

Rung 2: First Contactor (Low Speed)
|--[START_SEQUENCE]----------------------(TON_SPEED_1)---
                                         Timer: T4:3
                                         Preset: 20 (2.0 sec)
                    |
                    +---(CONTACTOR_1)---

Rung 3: Second Contactor (Medium Speed)
|--[T4:3/DN]--[START_SEQUENCE]----------(TON_SPEED_2)---
                                         Timer: T4:4
                                         Preset: 20 (2.0 sec)
              |
              +---(CONTACTOR_2)---

Rung 4: Third Contactor (Full Speed)
|--[T4:4/DN]--[START_SEQUENCE]----------(CONTACTOR_3)---
              |
              +---(MOTOR_AT_SPEED)---

Rung 5: Start Success Monitoring
|--[MOTOR_AT_SPEED]----------------------(MOTOR_RUNNING)---
|  |
|  +--[START_SEQUENCE]-------------------(START_SEQUENCE/)--

Rung 6: Start Failure Alarm
|--[T4:2/DN]--[MOTOR_RUNNING/]-----------(ALARM)---

Key Learning Points:

• Multiple timers coordinate complex sequences
• Monitoring logic ensures process completion
• Failure detection prevents equipment damage

Example 3: Batch Process Control with Mixing Timer

Application: Control automated mixing process with precise timing for ingredient addition and mixing duration.

Requirements:

• Fill tank for 30 seconds when FILL_START button pressed
• Wait 5 seconds for settling after filling
• Mix contents for 120 seconds
• Drain tank for 45 seconds
• Repeat cycle automatically if AUTO mode selected

Timer Logic:

Rung 1: Cycle Start Control
|--[FILL_START]--+--[AUTO_MODE]--[CYCLE_COMPLETE]--+---(CYCLE_ACTIVE)---
|                                                   |
+---[MANUAL_MODE]------------------------------------+

Rung 2: Fill Phase Timer
|--[CYCLE_ACTIVE]--[FILL_COMPLETE/]---------------(TON_FILL)---
                                                   Timer: T4:5
                                                   Preset: 300 (30.0 sec)
                   |
                   +---(FILL_VALVE)---

Rung 3: Fill Phase Completion
|--[T4:5/DN]--------------------------------------(FILL_COMPLETE)---
              |
              +---(TON_SETTLE)---
                  Timer: T4:6
                  Preset: 50 (5.0 sec)

Rung 4: Mixing Phase Timer
|--[T4:6/DN]--[MIX_COMPLETE/]------------------(TON_MIX)---
                                               Timer: T4:7
                                               Preset: 1200 (120.0 sec)
              |
              +---(MIXER_MOTOR)---

Rung 5: Mix Phase Completion
|--[T4:7/DN]-----------------------------------(MIX_COMPLETE)---
              |
              +---(TON_DRAIN)---
                  Timer: T4:8
                  Preset: 450 (45.0 sec)

Rung 6: Drain Phase Timer
|--[MIX_COMPLETE]--[DRAIN_COMPLETE/]-----------(DRAIN_VALVE)---

Rung 7: Drain Phase Completion and Cycle Reset
|--[T4:8/DN]-----------------------------------(DRAIN_COMPLETE)---
              |
              +---(CYCLE_COMPLETE)---
              |
              +---(CYCLE_ACTIVE/)---

Key Learning Points:

• Sequential process steps use timer done bits as triggers
• Process phases can be monitored individually
• Automatic cycle restart enables continuous operation

Example 4: Process restart inhibit after a stop

Application: Hold an ordinary process restart request for a defined period after a stop. This is status and sequence logic only; it is not the emergency-stop safety function.

Requirements:

• A separately engineered safety system removes or controls hazardous energy
• The standard PLC receives a read-only SafetyFunctionActive status
• Restart remains inhibited while that status is active
• After the safety system reports healthy, a process delay completes
• A new manual start edge is still required; no timer can auto-restart the machine

Platform-neutral pseudocode:

RestartDelay(
    IN := SafetyHealthy AND NOT SafetyFunctionActive,
    PT := Recipe.RestartDelay
);

ProcessRestartPermissive :=
    SafetyHealthy
    AND NOT SafetyFunctionActive
    AND RestartDelay.Q
    AND ResetSequenceComplete;

MotorStartCommand :=
    ProcessRestartPermissive
    AND StartButtonRisingEdge;

Test activation during timing, a bouncing status input, reset before expiry, controller restart and a held start button. The result must remain stop-dominant and require the approved reset/restart sequence. See E-stop PLC logic: safety circuit vs status code before using any safety-related signal.

Example 5: HVAC System Scheduling Timer

Application: Control building HVAC system with multiple time-based operating modes.

Requirements:

• Normal operating hours: 6:00 AM to 6:00 PM
• Setback mode outside normal hours
• Weekend shutdown with override capability
• Pre-occupancy startup 30 minutes before normal hours
• Post-occupancy run-on for 30 minutes

Timer Logic:

Rung 1: Current Time Comparison
|--[ALWAYS_ON]--------------------------------[GEQ]---
                                             Source A: CURRENT_TIME
                                             Source B: 600 (6:00 AM)
                                             |
                                             +---(AFTER_600AM)---

Rung 2: Operating Hours Detection  
|--[AFTER_600AM]--[CURRENT_TIME<1800]-------(NORMAL_HOURS)---

Rung 3: Pre-Occupancy Startup Timer
|--[AFTER_530AM]--[NORMAL_HOURS/]-----------(TON_PRESTART)---
                                            Timer: T4:10
                                            Preset: 1800 (30.0 min)

Rung 4: Post-Occupancy Run-On Timer
|--[NORMAL_HOURS]--+------------------------(TON_RUNON)---
|                  |                        Timer: T4:11
+--[T4:11/TT]------+                        Preset: 1800 (30.0 min)

Rung 5: HVAC System Enable
|--[NORMAL_HOURS]--+--[WEEKEND/]-----------(HVAC_ENABLE)---
|                  |
+--[T4:10/DN]------+
|                  |
+--[T4:11/DN]------+
|                  |
+--[OVERRIDE_SW]---+

Rung 6: Weekend Override Timer
|--[OVERRIDE_SW]--[WEEKEND]----------------(TON_WEEKEND)---
                                           Timer: T4:12
                                           Preset: 7200 (2.0 hrs)
                  |
                  +--[T4:12/TT]-----------(HVAC_ENABLE)---

Key Learning Points:

• Real-time clock integration enables scheduled operations
• Multiple timer conditions create complex operating modes
• Override functions provide operational flexibility
• Energy management reduces operational costs

Example 6: Pump Alternation System with Run Time Tracking

Application: Alternate between multiple pumps to ensure equal wear and track individual run times for maintenance.

Requirements:

• Three pumps available for duty rotation
• Lead pump runs until demand stops
• Pumps alternate as lead on each cycle
• Track individual pump run times
• Maintenance alarm after 500 hours operation

Timer Logic:

Rung 1: Pump Demand Detection
|--[PRESSURE_SWITCH/]--[MANUAL_STOP/]-------(PUMP_DEMAND)---

Rung 2: Lead Pump Selection Logic
|--[PUMP_DEMAND]--[PUMP_1_MAINT/]--[PUMP_1_FAULT/]--(SELECT_PUMP1)---
|
|--[PUMP_DEMAND]--[SELECT_PUMP1/]--[PUMP_2_MAINT/]--[PUMP_2_FAULT/]--(SELECT_PUMP2)---
|
|--[PUMP_DEMAND]--[SELECT_PUMP1/]--[SELECT_PUMP2/]--[PUMP_3_MAINT/]--[PUMP_3_FAULT/]--(SELECT_PUMP3)---

Rung 3: Pump 1 Control and Runtime Tracking
|--[SELECT_PUMP1]--------------------------(PUMP_1_RUN)---
                 |
                 +---(RTO_PUMP1_HOURS)---
                     Timer: T4:13
                     Preset: 50000 (500.0 hrs)

Rung 4: Pump 2 Control and Runtime Tracking
|--[SELECT_PUMP2]--------------------------(PUMP_2_RUN)---
                 |
                 +---(RTO_PUMP2_HOURS)---
                     Timer: T4:14
                     Preset: 50000 (500.0 hrs)

Rung 5: Pump 3 Control and Runtime Tracking
|--[SELECT_PUMP3]--------------------------(PUMP_3_RUN)---
                 |
                 +---(RTO_PUMP3_HOURS)---
                     Timer: T4:15
                     Preset: 50000 (500.0 hrs)

Rung 6: Maintenance Alarms
|--[T4:13/DN]------------------------------(PUMP_1_MAINT)---
|--[T4:14/DN]------------------------------(PUMP_2_MAINT)---  
|--[T4:15/DN]------------------------------(PUMP_3_MAINT)---

Rung 7: Lead Pump Rotation on Stop
|--[PUMP_DEMAND]--+--[PUMP_1_RUN]---------(LAST_LEAD_1)---
|                 |
+--[PUMP_DEMAND]--+--[PUMP_2_RUN]---------(LAST_LEAD_2)---
|                 |  
+--[PUMP_DEMAND]--+--[PUMP_3_RUN]---------(LAST_LEAD_3)---

Key Learning Points:

• Retentive accumulation across a power cycle must be verified for the exact controller and tag-memory configuration
• Equipment rotation logic ensures equal wear distribution
• Maintenance scheduling prevents unexpected failures
• Fault detection prevents damaged equipment operation

Example 7: Production Line Cycle Time Monitoring

Application: Monitor production cycle times and detect efficiency problems in manufacturing line.

Requirements:

• Measure time between product starts
• Calculate average cycle time over 10 products
• Alarm if cycle time exceeds target by 20%
• Reset statistics at shift change
• Display current and average cycle times

Timer Logic:

Rung 1: Production Cycle Detection
|--[PRODUCT_START]--[OSR_PRODUCT]----------(CYCLE_START)---
                    |
                    +---(TON_CYCLE)---
                        Timer: T4:16
                        Preset: 3600 (Maximum 60 min)

Rung 2: Cycle Time Capture
|--[CYCLE_START]--[PRODUCTION_ACTIVE]------[MOVE]---
                                           Source: T4:16.ACC
                                           Dest: CURRENT_CYCLE

Rung 3: Cycle Time Statistics
|--[CYCLE_START]---------------------------(ADD)---
                                          Source A: TOTAL_TIME
                                          Source B: CURRENT_CYCLE  
                                          Dest: TOTAL_TIME
                                          |
                                          +---(ADD)---
                                             Source A: CYCLE_COUNT
                                             Source B: 1
                                             Dest: CYCLE_COUNT

Rung 4: Average Calculation
|--[CYCLE_COUNT>=10]-----------------------(DIV)---
                                          Source A: TOTAL_TIME
                                          Source B: CYCLE_COUNT
                                          Dest: AVERAGE_CYCLE
                                          |
                                          +---(CYCLE_COUNT/)---
                                          |
                                          +---(TOTAL_TIME/)---

Rung 5: Cycle Time Alarm
|--[CURRENT_CYCLE>TARGET*1.2]-------------(CYCLE_ALARM)---

Rung 6: Shift Change Reset
|--[SHIFT_CHANGE]-------------------------(CYCLE_COUNT/)---
                 |
                 +---(TOTAL_TIME/)---
                 |
                 +---(AVERAGE_CYCLE/)---

Key Learning Points:

• Production monitoring requires statistical analysis
• Alarm thresholds detect process variations
• Data reset functions support shift operations
• Real-time feedback enables immediate corrections

Example 8: Temperature Control with Delay Compensation

Application: Demonstrate ordinary heating-control delays for thermal mass and sensor response.

Requirements:

• Start heating when temperature drops 2°F below setpoint
• Continue heating for 5 minutes minimum to avoid short cycling
• Stop heating when temperature reaches setpoint plus 1°F
• Provide 10-minute delay between heating cycles
• Remove the process heat request at an illustrative high-limit condition

Timer Logic:

Rung 1: Temperature Deviation Detection
|--[TEMP_PV<SETPOINT-2]--[SAFETY_OK]------(HEAT_REQUEST)---

Rung 2: Minimum Run Timer
|--[HEAT_REQUEST]--[HEATING/]-------------(TON_MIN_RUN)---
                                          Timer: T4:17
                                          Preset: 300 (5.0 min)

Rung 3: Heating Control Logic
|--[HEAT_REQUEST]--+--[TON_MIN_RUN/TT]---(HEATING)---
|                  |
+--[HEATING]-------+--[TEMP_PV<SETPOINT+1]---

Rung 4: Cycle Delay Timer  
|--[HEATING]--+------------------------------(TON_CYCLE_DELAY)---
|             |                              Timer: T4:18
+--[HEATING/]-+--[T4:18/TT]                  Preset: 600 (10.0 min)

Rung 5: Anti-Short Cycle Logic
|--[HEAT_REQUEST]--[T4:18/TT]--------------(HEAT_REQUEST/)---

Rung 6: High Temperature Safety
|--[TEMP_PV>SAFETY_LIMIT]-----------------(HEATING/)---
                            |
                            +---(SAFETY_OK/)---

Rung 7: Safety Reset Timer
|--[TEMP_PV<SAFETY_LIMIT-5]---------------(TON_SAFETY_RESET)---
                                          Timer: T4:19
                                          Preset: 300 (5.0 min)

Rung 8: Safety System Reset
|--[T4:19/DN]--[SAFETY_RESET_BUTTON]------(SAFETY_OK)---

Boundary: This sample high-limit bit is standard process logic. Where overheating can create a hazard, use the required independent or safety-rated protection, devices and validation.

Key Learning Points:

• Thermal systems require timing compensation for delays
• Minimum run times prevent equipment damage from cycling
• The engineered protective function must override normal heat-control logic
• Temperature differentials prevent oscillation

Example 9: Warehouse door sequence with obstruction status

Application: Illustrate an automatic-door sequence using an obstruction input. This is not a certified door-safety design.

Requirements:

• Door opens when vehicle approaches (proximity sensor)
• Door stays open for 60 seconds after vehicle passes
• Close door automatically if no obstacles detected
• Re-open immediately if obstacle detected during closing
• Manual override for maintenance access

Timer Logic:

Rung 1: Vehicle Detection
|--[VEHICLE_APPROACH]----------------------(DOOR_OPEN_REQ)---

Rung 2: Door Open Timer
|--[DOOR_OPEN_REQ]--[DOOR_CLOSED]---------(TON_DOOR_OPEN)---
                                          Timer: T4:20
                                          Preset: 30 (3.0 sec)

Rung 3: Door Fully Open Detection
|--[T4:20/DN]--[DOOR_OPEN_LIMIT]----------(DOOR_FULLY_OPEN)---

Rung 4: Keep-Open Timer
|--[DOOR_FULLY_OPEN]--+---[VEHICLE_CLEAR]--(TON_KEEP_OPEN)---
|                     |                    Timer: T4:21
+--[MANUAL_OVERRIDE]--+                    Preset: 600 (60.0 sec)

Rung 5: Door Close Request
|--[T4:21/DN]--[OBSTACLE_SENSOR/]---------(DOOR_CLOSE_REQ)---

Rung 6: Door Close Timer
|--[DOOR_CLOSE_REQ]--[DOOR_OPEN]----------(TON_DOOR_CLOSE)---
                                          Timer: T4:22
                                          Preset: 45 (4.5 sec)

Rung 7: Door Fully Closed Detection
|--[T4:22/DN]--[DOOR_CLOSE_LIMIT]---------(DOOR_FULLY_CLOSED)---

Rung 8: Obstacle Override Logic
|--[OBSTACLE_SENSOR]--[DOOR_CLOSE_REQ]----(DOOR_CLOSE_REQ/)---
                     |
                     +---(TON_KEEP_OPEN/)---
                     |
                     +---(TON_DOOR_CLOSE/)---

Key Learning Points:

• The selected protective devices and safety function must override automatic timing
• Sequential operations require interlocking
• Manual overrides support maintenance operations
• Obstacle detection prevents equipment damage

Example 10: Multi-Zone Irrigation Controller

Application: Control irrigation system with multiple zones, scheduling, and water conservation features.

Requirements:

• 8 irrigation zones with individual timing
• Prevent multiple zones operating simultaneously
• Daily schedule with start time and duration for each zone
• Moisture sensor override to skip watering
• Rain sensor lockout for 24 hours after rainfall
• Manual test mode for individual zones

Timer Logic:

Rung 1: Schedule Enable
|--[SCHEDULE_ACTIVE]--[RAIN_LOCKOUT/]-----(IRRIGATION_ENABLE)---

Rung 2: Zone Sequencer
|--[IRRIGATION_ENABLE]--[ZONE_ACTIVE/]---(ZONE_SEQUENCER)---
                       |
                       +---(TON_ZONE_DELAY)---
                           Timer: T4:23
                           Preset: 50 (5.0 sec between zones)

Rung 3: Zone 1 Control
|--[T4:23/DN]--[ZONE1_ENABLE]--[MOISTURE1/]-(TON_ZONE1)---
                                              Timer: T4:24
                                              Preset: ZONE1_TIME
                               |
                               +---(ZONE1_VALVE)---
                               |
                               +---(ZONE_ACTIVE)---

Rung 4: Zone 2 Control  
|--[T4:24/DN]--[ZONE2_ENABLE]--[MOISTURE2/]-(TON_ZONE2)---
                                              Timer: T4:25
                                              Preset: ZONE2_TIME
                               |
                               +---(ZONE2_VALVE)---
                               |
                               +---(ZONE_ACTIVE)---

[Continue pattern for zones 3-8]

Rung 10: Rain Sensor Lockout
|--[RAIN_SENSOR]-------------------------------(TON_RAIN_LOCKOUT)---
                                               Timer: T4:32
                                               Preset: 8640 (24 hours)
                |
                +---(RAIN_LOCKOUT)---

Rung 11: Manual Test Mode
|--[TEST_MODE]--[TEST_ZONE_SELECT=1]---------(ZONE1_VALVE)---
|--[TEST_MODE]--[TEST_ZONE_SELECT=2]---------(ZONE2_VALVE)---
[Continue for all zones]

Rung 12: System Status Display
|--[ZONE_ACTIVE]------------------------------[MOVE]---
                                             Source: Current Zone Number
                                             Dest: DISPLAY_ZONE

Key Learning Points:

• Sequential zone control prevents water pressure issues
• Environmental sensors provide automatic conservation
• Manual test modes support system commissioning
• Scheduling integration enables autonomous operation

Advanced Timer Programming Techniques

Mastering basic timer operations is just the beginning. Advanced timer programming techniques enable sophisticated control strategies that optimize system performance and reliability.

Cascaded Timer Systems

Cascaded timers create complex timing sequences by using the done bit of one timer to trigger the next timer in sequence. This technique is essential for multi-step processes requiring precise timing coordination.

Implementation Strategy:

Timer 1 (T4:0) → Timer 2 (T4:1) → Timer 3 (T4:2) → Process Complete

Each timer's done bit serves as the enable input for the subsequent timer, creating an automated sequence that requires minimal logic and provides excellent reliability. Cascaded systems excel in applications like chemical batch processes, equipment startup sequences, and multi-stage manufacturing operations.

Timer Calculations and Scaling

Advanced applications often require dynamic timer presets based on process conditions. Mathematical operations enable real-time timer adjustment based on production rates, environmental conditions, or operator inputs.

Dynamic Preset Calculation:

Base_Time × Speed_Factor × Quality_Multiplier = Dynamic_Preset

This technique allows single timer logic to adapt to varying process requirements without requiring separate timers for each condition. Production lines benefit significantly from this approach, automatically adjusting cycle times based on product variations.

Nested Timer Logic

Nested timers can provide process supervision: the primary timer controls normal operation while an independent timeout detects a sequence that exceeded its approved duration. Multiple ordinary timers do not create safety redundancy.

Example Implementation:

• Primary Timer: Normal process duration (5 minutes)
• Oversight Timer: Maximum allowable duration (7 minutes)
• Fault timeout: remove the process command and latch a diagnostic if the maximum duration is exceeded

This architecture ensures process reliability while providing multiple levels of protection against timing failures or process anomalies.

Timer State Machines

State machine programming uses timers to control transitions between operational modes. Each state has defined entry conditions, timing requirements, and exit criteria, creating robust process control.

State Machine Components:

1. State Definition: Current operational mode
2. Transition Conditions: Requirements for state changes
3. Timer Integration: Time-based state progression
4. Error Handling: Abnormal condition responses

State machines excel in batch processing, equipment sequencing, and complex automation systems requiring predictable behavior and error recovery.

Common Timer Programming Mistakes

Avoiding common timer programming errors significantly improves system reliability and reduces commissioning time. Understanding these pitfalls helps create robust timer logic from initial development.

Mistake 1: Overlapping Timer Functions

Programming multiple timers with conflicting or overlapping functions creates unpredictable system behavior. This commonly occurs when different programmers work on the same system or when modifications are made without understanding existing timer logic.

Problem Example:

Timer A: Controls pump start delay (5 seconds)
Timer B: Controls pump protection delay (3 seconds)
Both timers use the same input condition and affect pump operation

Solution Strategy:

• Document all timer functions and interactions
• Use unique, descriptive timer names
• Create timer allocation tables for complex systems
• Implement peer review for timer logic modifications

Mistake 2: Inadequate Reset Logic

Failing to provide proper timer reset conditions leads to timers that don't restart properly or accumulate unwanted timing values. This issue particularly affects retentive timers and complex sequential operations.

Common Reset Problems:

• Missing reset conditions for retentive timers
• Reset conditions that conflict with timing operations
• Inadequate power-up reset sequences
• Manual reset requirements not accessible to operators

Best Practice Solutions:

• Include reset conditions for all retentive timers
• Test reset logic under all operating conditions
• Provide manual reset capabilities where appropriate
• Document reset requirements in system manuals

Mistake 3: Incorrect Time Base Selection

Selecting inappropriate time bases causes timing accuracy problems and system performance issues. Time base selection affects both timing precision and scan time impact.

Time Base Guidelines:

• 0.01 second base: Legacy instructions that support it; verify task-period and resolution limits
• 0.1 second base: Standard industrial applications (motors, valves)
• 1.0 second base: Long-duration processes (batch, HVAC)
• Real-time clock: Scheduling and time-of-day functions

Mistake 4: Poor Timer Documentation

Inadequate timer documentation makes system maintenance difficult and increases the risk of programming errors during modifications. Good documentation practices prevent costly troubleshooting time and system downtime.

Documentation Requirements:

• Timer function descriptions
• Preset value justifications
• Input/output relationships
• Reset condition explanations
• Interaction with other system components

Timer Troubleshooting Guide

Systematic timer troubleshooting approaches quickly identify and resolve timing-related problems. Understanding common failure modes and diagnostic techniques minimizes system downtime.

Diagnostic Steps for Timer Problems

Step 1: Verify Timer Configuration

• Confirm timer address and type selection
• Check preset values against design specifications
• Validate time base settings
• Review timer enable conditions

Step 2: Monitor Timer Status Bits

• Enable Bit (EN): Confirms input condition status
• Timer Timing Bit (TT): Indicates active counting
• Done Bit (DN): Shows completion status
• Accumulated Value: Displays current timing progress

Step 3: Check Input Conditions

• Verify input signal presence and stability
• Test for intermittent input problems
• Confirm proper input device operation
• Check wiring and connection integrity

Step 4: Validate Output Operations

• Monitor timer output activation
• Test output device functionality
• Verify output wiring and connections
• Check for output device overload conditions

Common Timer Problems and Solutions

Problem: Timer Won't Start

• Possible Causes: Missing input signal, incorrect address, disabled timer
• Solutions: Check input conditions, verify timer configuration, test enable logic

Problem: Timer Runs But Won't Complete

• Possible Causes: Unstable input, incorrect preset, interrupted scan
• Solutions: Stabilize input conditions, verify preset values, check scan time

Problem: Timer Completes Too Early/Late

• Possible Causes: Wrong time base, incorrect preset calculation, scan time variations
• Solutions: Verify time base selection, recalculate presets, optimize scan time

Problem: Timer Won't Reset

• Possible Causes: Missing reset logic, continuous enable condition, hardware fault
• Solutions: Add reset conditions, modify enable logic, replace timer hardware

Advanced Diagnostic Techniques

Forced I/O Testing: Manually force timer inputs and outputs to isolate problems to specific system components. This technique quickly identifies whether problems exist in timer logic or connected devices.

Timeline Analysis: Record timer operation over complete cycles to identify timing irregularities, scan time impacts, and system performance variations.

Comparative Testing: Compare suspected faulty timers with known good timers using identical input conditions and preset values.

Best Practices for Timer Programming

Consistent timer programming and boundary tests make behavior easier to review and maintain.

Timer Selection Guidelines

Choose TON (Timer On-Delay) When:

• Delays are needed between input activation and output response
• Equipment requires startup delays or sequencing
• Process permissives need time verification
• Process steps require settling time

Choose TOF (Timer Off-Delay) When:

• Outputs must remain active after input deactivation
• Equipment needs run-on time for cooling or cleaning
• A non-hazardous process output needs an approved run-on interval
• Process completion requires extended operation

Choose RTO (Retentive Timer) When:

• The application requires accumulation across enable interruptions and verified retained memory
• Maintenance schedules track cumulative operation
• Process interruptions should not reset timing
• Equipment runtime totalization is required

Programming Standards and Conventions

Timer Addressing Standards:

• Use consistent numbering schemes across projects
• Group related timers in sequential addresses
• Reserve timer blocks for specific system functions
• Document timer allocation in project specifications

Naming Conventions:

• Include function description in timer names
• Use standard abbreviations for common applications
• Specify time units in timer documentation
• Include system area identification in names

Documentation Requirements:

• Function descriptions for all timers
• Preset value calculations and justifications
• Input/output relationship diagrams
• Reset condition explanations
• Maintenance and troubleshooting notes

Performance Optimization

Scan Time Considerations:

• Group timer logic to minimize scan impact
• Use appropriate time bases for application requirements
• Avoid unnecessary timer calculations in critical scan paths
• Monitor scan time impact during system commissioning

Memory Management:

• Allocate sufficient timer memory for system growth
• Use consistent timer file organization
• Reserve backup timers for critical applications
• Plan timer memory usage during system design

Reliability Enhancement:

• Include timer status monitoring in supervisory systems
• Implement timer backup strategies for critical functions
• Use watchdog timers for system health monitoring
• Plan timer testing procedures for commissioning

Frequently Asked Questions

What is a simple PLC timer program example?

Use a TON to supervise command-to-feedback time: when a valid request and permissives create RunCommand, execute the timer while RunCommand is true and RunFeedback is false. If feedback arrives before the preset, stop timing and report Running. If the timer completes first, remove the command and retain a diagnostic. Test the exact preset boundary, lost permissive, late feedback, reset and restart behavior on the target platform.

What's the difference between TON and TOF timers?

TON (Timer On-Delay) provides a delay between input activation and output activation. The timer starts counting when the input becomes true and activates the output after the preset time expires. TOF (Timer Off-Delay) works oppositely - the output activates immediately when the input becomes true, but the timer delays the output deactivation until the preset time expires after the input becomes false.

How do I calculate the correct preset value for my timer?

Timer preset calculation depends on your time base setting. For 0.01-second time base, multiply desired seconds by 100. For 0.1-second time base, multiply by 10. For 1.0-second time base, the preset equals the desired seconds. Example: 5 seconds with 0.1-second time base = 5 × 10 = 50 preset value.

Can I use the same timer in multiple rungs?

Yes, but use caution. The timer instruction should appear in only one rung, but timer status bits (EN, TT, DN) and values (ACC, PRE) can be referenced in multiple rungs. Using the same timer instruction in multiple rungs can cause unpredictable behavior and should be avoided.

Why does my timer reset unexpectedly?

Unexpected timer resets usually result from unstable input conditions, conflicting logic, or scan time issues. Check for intermittent input signals, ensure the timer enable condition remains stable, and verify that no other logic is resetting the timer unintentionally.

How do I create a timer that runs continuously?

Create a continuous timer using the timer's done bit to reset itself. Wire the done bit through normally closed contacts to reset the timer, or use the done bit to control reset logic. Be careful with this approach as it creates continuous timing cycles that consume scan time.

What happens to timers during power outages?

Power-cycle behavior is platform- and project-specific. Retentive instruction semantics do not guarantee that every associated value survives power loss; verify tag retentivity, startup logic, controller mode behavior and the instruction manual with the boundary test above.

How many timers can I use in my PLC program?

Timer capacity and execution cost vary by controller, memory and runtime implementation. Check the exact technical data and monitor memory plus worst-case task time with the intended number of active instances.

Can I change timer preset values while the program is running?

Many PLCs permit a variable preset, but behavior when it changes during timing is instruction-specific. Define whether edits are allowed, validate ranges and permissions, and test decreasing and increasing the preset on the target controller.

What is the difference between TP and a PLC one-shot?

A TP normally produces an output that remains true for a time preset after its trigger. A one-shot or rising-edge instruction normally produces a Boolean pulse for one program/task execution. They solve different duration requirements, and retrigger behavior still depends on the exact instruction.

Is a watchdog timer one of the normal PLC timer types?

Not in the same sense as TON, TOF or TP. A controller/task watchdog supervises execution time and can trigger a controller-specific fault or response. A communications watchdog checks data freshness, while a process timeout checks expected feedback. Name the failed layer and use the exact controller mechanism.

PLC timer type answer map

Question	Concise answer	Boundary to preserve
What are the main PLC timer types?	TON, TOF, TP and an accumulative/retentive form cover the main transition behaviors.	Names and exact semantics differ by platform.
What does TON do?	It delays Q becoming true until IN has remained true through the preset.	Ordinary TON reset and skipped-call behavior must be verified.
What does TOF do?	It makes Q true with IN, then delays Q becoming false after IN falls.	Reassertion during timing is vendor-specific in detail.
What does TP do?	It produces a timed pulse after its documented trigger, commonly a rising edge.	Test retrigger and cancellation behavior.
What is a retentive timer?	It holds accumulated progress across enable interruptions until reset.	Power-cycle retention is a separate controller/settings question.
Which timer creates a startup delay?	Normally a TON, with current permissives rechecked at the command.	A timer does not replace device feedback or safety logic.
Which timer creates fan run-on?	Normally a TOF or explicit state plus TON.	Delayed deactivation must be acceptable for that output.
Which timer creates a fixed pulse?	Normally TP or a vendor pulse block.	The physical output path and retrigger case require proof.
Is a cyclic timer standard?	No universal cyclic-timer mnemonic exists; build/test the periodic requirement or use a documented vendor block.	Define drift and pulse width.
Does timer resolution equal accuracy?	No; task/scan, I/O refresh, filtering and physical response also matter.	Measure end-to-end behavior.

Primary sources, review record and limitations

Reviewed August 30, 2026. The six figures on this page are original editorial illustrations retained from the established owner. They are conceptual teaching diagrams, not vendor screenshots, wiring drawings, timing guarantees or safety designs.

• IEC 61131-3:2025 publication record — current programming-language standard edition
• CODESYS Standard 3.5.22.0 library index — current standard timer set
• CODESYS TON function block
• CODESYS TOF function block
• CODESYS TP function block
• CODESYS TIME and LTIME literal reference
• Siemens S7-1200 V20 IEC timer operation — TP, TON, TOF and TONR
• Siemens V21 recommendation for IEC timer instances
• Siemens TONR time accumulator reference
• Rockwell Logix timer and counter instruction index
• Rockwell current TON reference
• Rockwell current TOF reference
• Rockwell current RTO reference
• Rockwell Logix 5000 General Instructions reference 1756-RM003
• Omron NJ/NX Instructions Reference Manual W502 — TON, TOF, TP, AccumulationTimer and Timer
• Schneider Machine Expert Standard timer index
• Schneider Machine Expert TOF reference
• Schneider timer-type and retentive-behavior support reference
• Mitsubishi MELSEC iQ-F FX5 instruction manual — standard and special timer instructions
• Mitsubishi FX5 program-design manual — timer, retentive timer and long-counter data boundaries

Vendor names and marks belong to their respective owners. This independent guide does not authorize changing a live preset, forcing timer state, delaying a protective response, bypassing a permissive or treating an ordinary PLC timer as a safety function. Verify the exact manuals, risk assessment, change procedure, representative hardware and acceptance evidence for the installed system.

---

Next test

Implement one TON, TOF and retentive timer using the same named signals, then run the eight boundary cases at the top of this page. Save the controller version and observed results beside the project so a later firmware or code change can be regression-tested.

Continue with the TON timer reference, TOF timer reference, retentive timer reference or the PLC scan-cycle explanation.