PLC Timer Programming: TON, TOF & Retentive Tests
Learn TON, TOF and retentive timer behavior with vendor-specific examples, timing diagrams, boundary tests and a reproducible PLC simulator matrix.
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.
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
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
Modern PLCs utilize three primary timer types, each designed for specific automation applications. Understanding when and how to use each type is fundamental to creating robust timer logic.
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
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:
- Define Timer Purpose: Determine whether you need ON-delay, OFF-delay, or retentive timing
- Set Preset Value: Calculate required timing based on process requirements
- Identify Input Conditions: Define what triggers timer operation
- Program Output Actions: Specify what happens when timer activates
- 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
SafetyFunctionActivestatus - 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:
- State Definition: Current operational mode
- Transition Conditions: Requirements for state changes
- Timer Integration: Time-based state progression
- 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'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.
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.
