Working with Programmable Timer Instructions in PLC Programming
Programmable Timer Instructions are one of those fundamentals you learn on day one and spend the rest of your career either trusting or troubleshooting. They're deceptively simple on paper. You set a preset value, a timing condition is met, and after a delay, an output changes state. In practice, they can eat up half your debugging time if you don't know what you're looking for. There are two main types you'll encounter: on-delay timers and off-delay timers. An on-delay timer starts counting when its enable bit goes true, and only activates its output after the preset time has elapsed. An off-delay timer does the opposite — its output turns on immediately when enabled and then delays turning off once the enable condition goes false. Then there are retentive timers, which hold their accumulated value even when power is lost or the enable bit goes false, until you explicitly reset them. I still see engineers accidentally using non-retentive timers in processes where a power blink should preserve the elapsed time, and it takes a while before you stop making that mistake yourself.
Implementing Programmable Timer Instructions Correctly
Setting these up correctly means understanding scan time. PLCs don't operate in real time the way humans think of it. They scan through your logic in a cycle that typically runs anywhere from a few milliseconds to tens of milliseconds depending on your controller and program size. A timer instruction only evaluates during that scan. If your timer preset is set to 50 milliseconds on a PLC with a scan time of 30 milliseconds, you need to understand what that actually means for your application. The timer won't activate on the first scan even if the condition is true. It will accumulate during scan one, continue during scan two, and only trigger partway through scan three. Small timers relative to scan time introduce uncertainty you might not want in precision applications. Here's a concrete example. I was working on a packaging line where we needed to control the opening of a pneumatic valve for exactly 200 milliseconds to punch a hole in a conveyor belt product. We set a TON timer with a preset of 200, used milliseconds as the time base, and wired the enable and output contacts. Worked fine in the simulator. Then we put it on the actual PLC and the holes were inconsistent. Some products got double-punched, some got nothing. The issue was that the enable condition was tied to a sensor that had mechanical bounce. The contact would open and close rapidly during the trigger window, causing the timer to reset and restart repeatedly instead of running its full preset. The fix was straightforward — add a one-shot pulse to the enable input so the timer only arms once per trigger event, regardless of contact chatter. I should have thought of that before writing the first draft. One thing most people don't realize about Programmable Timer Instructions is how the accumulator and preset interact when you're using different time bases. If your timer instruction uses a 1 millisecond time base and your preset is 5000, that's five seconds. But if your PLC's scan time is, say, 8 milliseconds, the timer will miss approximately 3 milliseconds of timing on every single accumulation cycle. Over a five-second interval, you're losing roughly 1.5% of your timing accuracy. That seems minor until you're working on high-speed production equipment where cumulative drift matters. For anything under 100 milliseconds where precision matters, check your manual and see if your controller supports a dedicated hardware timer block instead of relying on the standard software-based timer instruction. Hardware timers operate independently of the scan cycle and won't have this problem.
Another common pitfall involves timer overlap in ladder logic. When you have multiple timers stacked in a rung and one timer's output feeds into the next timer's enable, the scan order determines whether the sequence behaves as expected. Most PLCs execute logic from top to bottom within a scan, so a timer placed earlier in the program will update its accumulator before a later timer gets a chance to see its result. Swap the order and you might get completely different behavior at the same preset values. This isn't theory. I spent a full afternoon tracking down why a two-stage heating sequence would sometimes skip the second stage entirely. The second heater's timer was enabled by the first heater's done bit, but the first heater's timer was physically located after the second one in the ladder program. The second timer was reading the first timer's done bit from the previous scan, not the current one, creating a one-scan delay that occasionally caused synchronization issues at higher cycle rates. Moving the first timer above the second one in the program resolved it immediately. Retentive timers deserve special attention because they create state that persists across scans in a way that regular timers don't. The accumulated value remains after a power loss or a disable condition, which is useful but also dangerous if you assume the accumulator is zero at startup. I've seen retentive timers initialized to random values after a hard reset because the memory wasn't cleared, and the downstream logic acted on stale timing data for the first few cycles. Always include an initialization routine that resets your retentive timers on startup, or better yet, use the controller's default data table wipe function if your PLC supports it. Most modern controllers have a built-in option for this during the power-up sequence. If you're looking for documentation or a download to get started, the specific implementation varies by manufacturer. Rockwell Allen-Bradley uses TON, TOF, and RTO instructions. Siemens uses CTU, CTD, and CTUD function blocks in their TIA Portal environment. Mitsubishi uses T and ST instructions depending on the model. Each has its own addressing conventions and parameter layouts. The underlying principles are identical across platforms, so once you understand how the accumulator, preset, and enable bits interact, switching between manufacturers is mostly a matter of learning the syntax. The hard part — and the part that actually matters — is understanding the timing behavior relative to scan cycles and real-world process constraints.
Get the Full Details
