Fix a PLC hour compare: single word, not double

What symptoms point at the wrong data width?

Three symptoms point at data width: a compare that never comes true at any hour, an output that switches at hours nobody entered, and a monitored value sitting 65,536 or more above the 0 to 23 you typed. Each one has a distinct cause, so match what you see on screen to the list before touching the rung.

• The rung is never true, at any hour. The double-word compare pairs each named register with the one after it. Those two extra registers hold whatever the rest of the program left there, so equality now needs the two hours and the two neighbours to match at the same scan. A rung that ORs the compare's result bits (SP60 or SP61 as written in the failing logic) hides the cause further.
• The output switches at hours nobody set, or changes behaviour after an unrelated edit. The neighbour registers belong to other logic; when something writes them, the two 32-bit operands move and the compare's truth table moves with them.
• V1400 never shows the value entered at the panel. That is an entry-write problem before it is a compare problem; work through an HMI numeric entry that resets to 0 after entry first, because a correct compare cannot rescue a value that never arrives.
• The register reads a five-digit number, or two values glued together. The width is right here; the representation is wrong. Set the signed decimal data format, or read nonsense numbers from a PLC BCD analog register if the digits look like two packed values.

Why does a double-word compare fail on hour values?

The hour of day runs 0 to 23, so both sides of the compare fit one 16-bit word, which holds 0 to 65,535; a double-word compare instead builds each operand from two registers and compares numbers nobody wrote. The width mismatch is the whole failure.

The data types come from IEC 61131-3, the standard behind WORD and DWORD: a WORD is 16 bits, a DWORD is 32 bits and is built from two consecutive words. Move, compare and math instructions are typed on every platform, so a double-word compare expects each operand assembled from V1400 plus the next register, and from V7770 plus the next register. Your hour values use only the first register of each pair.

When the processor assembles a pair, it scales one word by 65,536 (2 to the 16th power) and adds the other. One count in the scaled word moves the combined value 65,536 steps, about 2,849 times the whole 0 to 23 range. Which word of the pair gets scaled varies by platform; either way, equality now needs the two neighbour registers to match as well as the two hours. If both neighbours happen to sit at 0, the double-word version can even appear to work, which is why this bug shows up in one project and not the next.

A knowledge-base page on single-word versus double-word data overflow walks the same width mismatch on another PLC family, if you want a second treatment.

What does the fixed rung look like?

Replace the load-and-compare pair with one inline single-word relational contact, the working form: V7770 >= V1400 driving OUT Y0, with the clock hour on the left of the operator and the panel entry on the right.

V7770 >= V1400   ----( Y0 )

One contact, one coil. The processor fetches two 16-bit words, compares them and sets Y0 from the relation in the same scan. There is no accumulator step and no result bit to branch on, so the SP60 and SP61 contacts from the old rung disappear. If your ladder offers no inline relational contact, run the single-word compare instruction and branch on its result; the width is the point, and the block form with a 16-bit compare behaves the same.

Confirm two addresses before you trust the rung: the PLC manual must document V7770 as the clock's hour register, counting 0 to 23, and the panel project must write its numeric entry to V1400. If the panel writes somewhere else, fix that first; a correct compare cannot rescue a value that never arrives.

Which operator fits the schedule: at or after, or exactly at?

Pick >= when the output should stay on from the entered hour to midnight, and = when it should be on for that one hour only; the choice decides whether a lamp set for 14 burns for 10 hours or 1.

With entry 14, the >= rung is true at 14, 15, 16 and on through 23, ten hour-values, so it suits a lamp, a heater disable or an open sign that runs until midnight. The = rung is true only while the clock shows exactly 14, one hour, which suits a once-a-day event. The old rung ORed two result bits into one output; whatever each bit means on your platform, the inline contact makes the relation explicit and readable.

One boundary to plan for: a single >= turns off at midnight, because 0 >= 14 is false at 00:00. A window that crosses midnight needs both relations ORed, (V7770 >= 22) OR (V7770 <= 4), which covers 22:00 through 04:59.

What does a worked example of the day look like?

This example walks one shift lamp through a full day: the panel writes 14 (2 pm) into V1400, the clock hour sits in V7770, and Y0 drives the lamp on the at-or-after schedule, V7770 >= V1400.

The day, read straight off the rung:

The lamp burns from 14:00 to midnight, 10 hours. Swap the contact to = and the same table gives 1 hour, 14:00 to 14:59.

Now the old double-word version at the same 14:00 moment. Say the register after V1400 holds 8 of leftover program data and the register after V7770 holds 30; assume the neighbour is the high word of each pair (if your platform scales the first word instead, the arithmetic mirrors and the conclusion holds). The entry side loads 14 + 8 x 65,536 = 14 + 524,288 = 524,302. The clock side loads 14 + 30 x 65,536 = 14 + 1,966,080 = 1,966,094. Both hours are 14, yet 524,302 = 1,966,094 is false, so the double compare reports a mismatch and the lamp stays dark. The single-word compare reads 14 >= 14 and the lamp lights.

A machine lamp is the smallest case of this. If the plant also wants the hour and shift plan visible on a wall, we build shop-floor screens that play such boards offline; the ladder keeps driving the load, the board only shows it.

How do you check the fix before the machine runs?

Test the rung with the machine in a safe state: watch V1400 and V7770 live, walk the clock hour past each boundary, and confirm 0, 13, 14 and 23 do what the schedule intends.

1. Make the load safe first: disconnect the lamp or actuator Y0 drives, or apply your plant's lockout step, so a surprise pulse during testing starts nothing.
2. Enter 0 and then 23 at the panel and watch V1400 in the PLC. Both must arrive as plain decimal values. An entry that bounces back to 0, or arrives scaled, is an entry problem, and the linked articles in the symptom list are the place to start.
3. Watch V7770 across one real hour change and confirm it steps the way the PLC manual documents, 0 to 23 with the wrap at midnight.
4. Evaluate the rung against 0, 13, 14 and 23. With entry 14 and the >= contact, expect off, off, on, on. If it is already on at 13, the operands are reversed; swap the sides of the operator.
5. If the contact is true and Y0 still misbehaves, search the program for every other coil on Y0; a second rung writing the same address overrides this one.

How do you keep the entry inside 0 to 23?

Accept 0 to 23 at the panel and reject anything wider in the PLC, because a 4-digit thumbwheel that takes 99 turns an hour entry into 99, a value no clock hour can ever match.

Most numeric entry objects expose a minimum and maximum; set 0 and 23 there in the panel project. If your panel has no range fields, the PLC-side check becomes the only guard. Add one rung that treats V1400 > 23 as invalid: hold Y0 forced off, or write 0 back into V1400 and flag the bad entry, whichever behaviour the operator expects. Write it explicitly; a compare fed an out-of-range value produces an out-of-range decision, and at 99 the >= contact is simply true all night.

Test all three cases from the panel: 0, 23 and an invalid 99. The valid pair must behave per the worked example; the invalid one must never drive Y0.

Recommendation: replace the LDD V1400 and CMPD V7770 pair with the inline single-word contact V7770 >= V1400 driving OUT Y0 whenever both operands are hour-of-day registers holding 0 to 23; use = in place of >= only when the output must run for that single hour; and before the panel goes back on the wall, set the 0 to 23 entry limits and prove the invalid-entry behaviour with a 99.

Questions