Build a PLC seconds countdown with a one-second clock

Why does a 16-bit V-memory word overflow a 999:59 timer preset?

Because the ×10 timer-resolution step turns the largest entry into 599,990, and one 16-bit word tops out at 65,535: 999 minutes × 60 seconds × 10 = 599,990, which needs 20 bits, so the word throws away everything above bit 16.

At 0.1-second timer resolution a preset carries seconds × 10. The largest operator entry is 999:59, so 999 × 60 = 59,940, plus 59 gives 59,999 seconds, times 10 gives 599,990 timer ticks. An unsigned 16-bit word tops out at 2^16 - 1 = 65,535, and even that ceiling carries only 6,553.5 seconds, about 1 hour 49 minutes of preset. The original plan to hang a counter above the overflow works, but it splits one timing job across a counter and two timers and needs a remainder translation for the leftover seconds. The width and the format each break a different part of the value, and the next section shows the format breaking first.

Why does a 16:50 entry show as 100 in V-memory?

Because the value travels through the arithmetic as BCD, and 10,100 needs five BCD digits at 4 bits each, 20 bits total; a 16-bit word keeps only the last four digits, so 10,100 arrives as 0100, which reads as 100.

BCD stores one decimal digit per 4 bits, so five digits need 20 bits and the largest decimal number whose BCD fits one word is 9,999. In the ×10 scale, 9,999 ticks is 999.9 seconds, which is why the design worked through 16:39 and broke at 16:40. At 16:40 the entry is 1,000 seconds, 10,000 ticks, five digits, and the word reads 0. Binary would be fine: 10,100 is 0x2774, an easy fit. The format is the limit, not the width.

The compare gating the whole split path makes it worse. 9,600 is 16 minutes × 60 seconds × 10, and a truncated word never gets near it, so the counter-plus-two-timers branch is dead code that never runs.

Symptoms and what each points to:

• An entry above 16:39 displays chopped, 16:50 as 100 and 16:40 as 0: five-digit BCD truncation in the ×10 preset path.
• The long-cycle branch never triggers: the truncated word never reaches the 9,600 threshold.
• A countdown from a small value shows a hex-style word like F3D4 and falls far faster than one second: the DEC is enabled on every scan, and the watch format is wrong (both covered below).
• The countdown runs at the right speed but the HMI shows the wrong digits: the HMI tag format and the word disagree, the same mismatch that produces nonsense numbers from a BCD analog register.

Can one 16-bit word hold 999:59 in plain seconds?

Yes: drop the ×10 and the same 999:59 entry becomes 999 × 60 + 59 = 59,999 plain seconds, which an unsigned 16-bit word holds with more than 5,000 counts to spare, at the cost of one-second resolution.

Nothing else in the design gets harder: no division, no remainder translation, no counter cascade. One word, one decrement, one compare. The cost is resolution, because the countdown moves in 1-second steps and the 0.1-second timer base is gone. If the machine cycle needs tenths of a second, stop here and keep the timers.

The one check that decides the range is signedness. Some DEC instructions, compares and HMI tags treat a 16-bit word as signed, and a signed word's positive ceiling is 2^15 - 1 = 32,767 seconds, which is 546 min 7 s, about 9 hours 6 minutes. Entries past that need unsigned handling end to end, or a second word. The test is one move: load 40,000 into the word and read it back. A monitor showing -25,536 means some element in the path is signed, and the ceiling above is the one you have.

How do I decrement a seconds register once per second with SP4?

Gate a PD one-shot with SP4, the clock bit that is true for 500 ms of every second, and let each one-shot pulse enable exactly one DEC instruction: one pulse per clock, one count per second, no repetition inside the second.

1. On the cycle-start bit, move minutes × 60 + seconds into the countdown word. No ×10 anywhere in the arithmetic.
2. Build the clock rung: SP4 contact into a PD positive-differential one-shot. PD closes for exactly one scan on each rising edge of SP4, once per second.
3. Let the PD contact enable one DEC on the countdown word. Use DEC for binary data and DECB for BCD data; the instruction must match the format the word actually holds.
4. Add the completion rung: a compare, word equals 0, latches the event bit.
5. Keep the scan time comfortably below 500 ms so no SP4 on-window is skipped; a scan stretched past the window misses whole pulses and the count loses seconds.

A count-up variant works the same way with INC and a compare against the target, if decrementing reads worse in your logic. The panel can show the remaining seconds during the run, and the PLC countdown timer display setup covers the HMI side. Without the PD, DEC executes on every scan while SP4 is on, which is the fault in the next section.

Why does my countdown show F3D4 and fall much faster than one second?

F3D4 reads as 62,420 unsigned or -3,116 signed, and from a 300 start that is 3,416 decrements past zero, which no once-per-second clock produces: the DEC is firing on every scan inside the clock's on-window, and the watch window is showing binary.

Both halves share one cause: the DEC is wired straight to SP4. The clock is on for half of every second, so a direct contact lets the instruction run on every scan inside that window. At a 2 ms scan period, 500 ms / 2 ms = up to 250 decrements in a single second. The word runs through zero into two's-complement territory: 300 - 3,416 = -3,116, which a hexadecimal or signed monitor displays as F3D4.

The repair is one instruction: insert the PD between the SP4 contact and the DEC. Reload 300, confirm the monitor shows decimal 300, and watch one decrement per second, zero reached after 300 seconds, five minutes on a stopwatch. If the value still misbehaves with PD in place, the remaining suspect is format: the word may hold BCD while DEC assumes binary, so switch between DEC and DECB until the readback matches what you loaded.

What does a worked example look like for a 16:50 entry?

An operator enters 16 minutes 50 seconds: the new path stores 16 × 60 + 50 = 1,010 seconds, subtracts one per SP4 pulse, and fires the event on the 1,010th pulse, 16 minutes 50 seconds after the start, accurate to one second.

Old path: 16 × 60 = 960, plus 50 gives 1,010 seconds, times 10 gives 10,100 ticks. Five BCD digits, 20 bits, the word keeps four: 0100, displayed as 100. The compare against 9,600 never fires, so no counter, no split, no event.

New path: the same entry stores 1,010 directly. SP4 rises once per second, PD closes for one scan, DEC subtracts one. After the 1,010th pulse the word reads 0, the compare latches the event, and elapsed time is 16 min 50 s within one second. The word never leaves 0 to 1,010, far inside one unsigned word.

Without the one-shot at a 2 ms scan, the same 1,010 counts vanish in about 1,010 × 2 ms = 2 s of on-window scanning, and the word sits deep in negative territory long before the cycle should end.

The table pins the break: 16:39 is the last entry the timer path can carry, and 16:40 is the first one it destroys. If the panel should show remaining time as 16:49, 16:48 and downward, converting a seconds counter to minutes and seconds is a two-instruction job at the HMI.

What checks do I run before the machine goes back into production?

Run four checks with the machine stopped: confirm a known value reads back in decimal, confirm one decrement per clock pulse, time a short preset against a stopwatch, then enter the 999:59 maximum and prove the completion path at zero.

1. Format: load 300 and read it back in the PLC's own monitor as decimal 300. Then load 40,000: a readback of -25,536 means some element treats the word as signed, and the positive range shrinks to the signed ceiling from the range section.
2. Pulses: watch the word across five SP4 pulses. Exactly five decrements, no movement between pulses.
3. Short timing: enter 0:10 and stopwatch the cycle. Completion between 10 and 11 seconds is correct for one-second resolution.
4. Range: enter 999:59 and confirm the word reads 59,999, the compare targets 0, and the event resets cleanly for the next cycle.
5. Completion gating: prove the event bit fires only from the compare rung, then restart the cycle twice to confirm repeat behavior.

A word that passes all five runs production. Each failure maps to a section above, and every one is a format or trigger fault, never a capacity fault.

When should I keep the timer-preset design instead?

Keep the timer-preset design when the cycle needs 0.1-second accuracy, and for any entry at or below 16:39 where the ×10 BCD value still fits; switch everything longer to the seconds countdown.

Timer time bases carry their own scan-time rules, printed in the instruction set reference: one widely used reference states its 0.01-second base maintains accuracy with program scans up to 2.5 seconds. The one-second software clock trades that for a simpler rule, the scan staying under the clock's 500 ms on-window. For long entries the seconds design wins on range and simplicity; for short cycles that genuinely need a tenth of a second, the timer stays. The split design sketched in the original plan, counter plus two timers above 16 minutes, stays valid for 0.1-second work past 16:39, remainder translation included. And when an HMI-written preset starts coming back zero between cycles, that fault has its own reset-path checklist.

Recommendation: Convert entries to seconds and drive one DEC through a PD one-shot off SP4 whenever whole-second resolution is acceptable and entries must run past 16:39, confirming signed-versus-unsigned handling before any entry climbs past the signed ceiling. Keep the ×10 timer-preset path, split into a counter-plus-timer pair above 16:39, only for cycles that need 0.1-second accuracy.

Questions