Pack PLC hour and minute into one HHMM integer

The answer: hour × 100 plus minute

On a CLICK PLC the real time clock feeds two system data registers: SD24 _RTC_Hour holds the hour, 0 to 23, and SD25 _RTC_Minute holds the minute, 0 to 59, both plain integers. The clock data refreshes into these registers on a 1 second cycle, so the packed value lags the wall clock by under a second. The first schedule built from these registers, rung by rung, is covered in Schedule a PLC output from the real time clock.

Pack the current time with a math rung:

(SD24 * 100) + SD25

At 23:30 this reads (23 × 100) + 30 = 2330. Pack the setpoint the same way, from two entry fields into two integer registers, and the whole schedule reduces to one compare: packed current time equals packed setpoint. The individual fields stay readable for troubleshooting, and if a compare on the hour field alone misbehaves, the usual register-width cause is covered in Fix a PLC hour compare: single word, not double.

2330 fits a 16-bit signed integer with room to spare; that format tops out at 32767.

Why minute × 0.01 fails the compare

Adding minute × 0.01 to the hour gives 23.30 on a calculator, and that is where the method breaks on a PLC. A 32-bit float carries about seven significant decimal digits, so it stores 0.01 as a value a few parts in ten million off. The minute product and the typed literal 23.30 each round along their own path, and for some hour and minute pairs the two results land a step apart in the last stored digit, so the equality compare misses the minute it was supposed to catch. Both values still display as 23.30, so the miss stays invisible until the night the event never fires.

Integers behave the opposite way. 2330 is 2330 in every scan, and (23 × 100) + 30 produces exactly the value stored in the setpoint register. That is the whole reason to pack before comparing: equality needs two identical integers, and integer arithmetic produces the same value on both sides of the compare.

The decimal form carries a second trap. 23.30 reads as a fractional hour, 23 and 30 hundredths of an hour, which converts to 23 hours 18 minutes, 12 minutes off the time the operator set. Nothing in the PLC converts it back, so any hour-based math downstream inherits the error. Keep the packed integer for clock matching and keep hour fractions out of the program.

What the HMI shows for 2330

Set the numeric display to two decimal positions and 2330 shows as 23.30. The register still holds the integer 2330; the decimal point exists in the display formatting and nowhere else.

Leading zeros need a second setting. Hour 7 and minute 5 pack as (7 × 100) + 5 = 705, and two decimal positions render that as 7.05 until the field pads to four digits. Set the digit count to 4 and it reads 07.05. Decimal positions alone never produce the leading zero, so set the digit count on the same screen.

Two decimal positions also fix the separator as a period. If operators need 23:30 with a colon, that formatting comes from a clock or text display fed with the hour and minute fields; Show a digital clock on an HMI panel from PLC RTC values walks through that build. Keep the two entry fields separate: one numeric entry writes the hour, one writes the minute, and the PLC packs them. Each field then keeps its own range visible to the operator, which is what makes the validation below simple.

Worked example: schedule an event at 23:30

Inputs, with their sources:

• SD24 _RTC_Hour = 23, range 0 to 23, from the vendor's register list, refreshed from the clock on a 1 second cycle
• SD25 _RTC_Minute = 30, range 0 to 59, same source
• Setpoint hour = 23 and setpoint minute = 30, entered on the HMI into two integer registers, validated 0 to 23 and 0 to 59 before packing

Rule: packed time = hour × 100 + minute, applied to the clock pair and to the setpoint pair.

Arithmetic:

• Current = (23 × 100) + 30 = 2300 + 30 = 2330
• Setpoint = (23 × 100) + 30 = 2300 + 30 = 2330
• Compare: 2330 = 2330, equality true, the event rung energizes

Timing: SD25 rolls from 30 to 31 after 60 seconds, and the 1 second register refresh puts the drop-out within about a second of that roll. The rung is true for close to a full minute of scans. At 23:31 the current value reads (23 × 100) + 31 = 2331, the compare drops out, and 2330 never matches again that day.

Decision: with a plain output coil on the rung, the action stays energized for that whole minute. Add a done bit instead: on the first scan where the compare is true and the done bit is off, fire the action and set the done bit; when the compare drops out, reset the done bit. The event fires once at 23:30 and the schedule re-arms itself for the next day.

Entry ranges and the restart case

Validate before packing. A minute entry of 60 packs as (23 × 100) + 60 = 2360, a value no clock register ever produces, so the event would sit armed and never fire. Reject an hour above 23 and a minute above 59, and keep the schedule disabled, or hold the last valid packed setpoint, while either field sits outside 0 to 23 or 0 to 59. Recalculate the packed setpoint when either entry changes or when the operator confirms the pair.

Decide the restart behavior of the done bit. After a power loss inside the matching minute, a non-retentive done bit reads false again and the event fires a second time. If a second firing is wrong for the machine, hold the done bit in retentive memory and clear it at a schedule boundary or on operator reset.

Keep HHMM out of duration math

HHMM orders digits; it does not count time. From 23:59 to 00:00 is one minute, but 0 − 2359 gives −2359, and 2359 + 1 gives 2360, a time that exists on no clock. Convert to plain minutes first, hour × 60 + minute, do the subtraction or addition there, and format the result back for display. For running totals the raw fields add directly; Add minutes and seconds to a total time display on a PLC shows that arithmetic. The packed integer has one job, matching a wall-clock time, and integer equality does that job exactly.

Test it before the machine sees it

Check the math and the display apart from the machine action. At any moment, four values should agree: the two clock registers, the packed current time, the two entry fields, and the packed setpoint. Three boundaries catch most packing mistakes:

• Single digits: 7:05 packs to 705 and displays as 07.05 with the digit count at 4, as 7.05 without it.
• Midnight: 23:59 packs to 2359, and (0 × 100) + 0 = 0 at 00:00, so a setpoint of 0 compares cleanly.
• The scheduled minute: equality turns on inside the matching minute only, and the done bit holds the action to one firing.

Then enter minute 60 and confirm the schedule cannot arm, and watch one full event through its matching minute to confirm the action happens exactly once.

The decision

Recommendation: pack both times as hour × 100 + minute, compare the two integers in one rung, and latch a done bit that resets when the compare drops out. Keep the two entry fields separate, validate 0 to 23 and 0 to 59 before packing, and show the packed value on one numeric display with two decimal positions and the digit count set to 4. Leave minute × 0.01 out of every equality compare, and run any duration math in plain minutes.

Questions