Writing a register from the HMI does not set a Do-more clock; the time lives in SDT0 and changes only through SETTIME, fed from a User Date/Time block. Stage year through second in V100 to V105, validate the calendar date, then run SETTIME once from an Accept pushbutton, because SETTIME normalizes an impossible date, turning February 31 into March 3.
Writing a value from the HMI into the PLC does not set a Do-more clock. The running time sits in the system date and time structure SDT0, and one instruction changes it: SETTIME, taking a User Date/Time block such as UDT10 as its source. The setup that survives real use is staging plus one commit. The panel writes year through second into six plain registers, V100 to V105. Ladder moves them into UDT10, checks the calendar, and runs SETTIME once from an Accept pushbutton. The check is the part worth building, because SETTIME normalizes an impossible date instead of refusing it: February 31 becomes March 3, with no error shown to anyone. The same screen serves the daylight saving time change twice a year.
What SETTIME does with what you give it
SDT0 holds the live date and time. Read its members anywhere you want to show time on the panel. SETTIME is the only writer, and it takes its new time from a User Date/Time block you create in System Configuration. This article uses UDT10, whose members are Year, Month, Day, Hour, Minute, Second and DayOfWeek.
The instruction is edge triggered, marked by the power-flow triangle on its box, so it runs once per false-to-true transition of its input. Its Source Type is Local or UTC. Choose Local when the staged values are wall time, which is the normal manual correction. Choose UTC only when the values really are UTC.
The behavior that shapes the whole design: SETTIME does not refuse an impossible date. It rolls the overflow forward, so a block reading February 31 lands the clock on March 3. After any set, the system time read-back value gives you the system time to compare against the staged block.
Why the staging registers sit in V memory
When the panel's tag browser cannot drill into the block, it offers the whole Date or Time group, such as UDT10.Date, with no path down to UDT10.Year. Plain V registers solve that, because every HMI writes integers. The panel writes six registers, and one MOVE per field carries them into the block:
| HMI entry | Staging register | MOVE destination |
|---|---|---|
| Year, four digits | V100 | UDT10.Year |
| Month, 1 to 12 | V101 | UDT10.Month |
| Day, 1 to 31 | V102 | UDT10.Day |
| Hour, 0 to 23 | V103 | UDT10.Hour |
| Minute, 0 to 59 | V104 | UDT10.Minute |
| Second, 0 to 59 | V105 | UDT10.Second |
Enter the year as four digits; a two-digit entry leaves the century unresolved. Leave DayOfWeek alone: the controller calculates it from the date you set.
What you need
- UDT10, a User Date/Time block from System Configuration.
- Six writable integer registers, V100 through V105, in the HMI tag database.
- One discrete bit for the Accept action; this example uses C0, and any spare coil works.
- Six MOVE instructions and the range checks from the next section.
- SETTIME with UDT10 as its source.
- Two lamps on the screen: accepted and rejected.
Build the screen and the ladder
- Create UDT10 in System Configuration as a User Date/Time structure.
- Put six numeric entry fields on a setup screen, bound to V100 through V105. Clamp each field in the entry object: month 1 to 12, day 1 to 31, hour 0 to 23, minute 0 to 59, second 0 to 59, year four digits.
- When the screen opens, copy the six fields out of SDT0 into V100 through V105, so the operator edits from the running time instead of from zeros.
- Add an Accept pushbutton that writes C0, plus the accepted and rejected lamps.
- On the rising edge of C0, run the six moves: V100 to UDT10.Year, V101 to UDT10.Month, V102 to UDT10.Day, V103 to UDT10.Hour, V104 to UDT10.Minute, V105 to UDT10.Second.
- Run the calendar checks on the staged values in the same scan. Any failure lights the rejected lamp and blocks SETTIME for that press.
- With every check passed, execute SETTIME with UDT10 as the source and Source Type Local. One press gives one execution, because the instruction is edge triggered.
- Leave the time display reading SDT0, and let nothing on a display screen write to the clock.
Set the clock with the machine in a safe state. Anything the program runs from the real-time clock, such as a scheduled output, can fire or be skipped when the time jumps.
The calendar check that runs before SETTIME
| Month | Last valid day |
|---|---|
| January, March, May, July, August, October, December | 31 |
| April, June, September, November | 30 |
| February | 28, or 29 in a leap year |
A year is a leap year when it divides by 4, and a century year also has to divide by 400. So 2024 was a leap year, 2026 is not, and 2100 will not be.
Reject the press when the month is under 1 or over 12, the day is under 1 or past the month's last day, the hour is over 23, the minute or second is over 59, or the year did not arrive as four digits. The refusal is the point. SETTIME takes what it is given and rolls overflow forward, so the program has to be the one that says no. It is the same guard pattern as validating setpoints before they reach the PLC, applied to a date.
Example: changing March 31 to February 20
The clock reads March 31, 2026, 09:12. The operator wants February 20, 2026, 09:12.
With SETTIME triggered from field changes, the edit fails on the second keystroke. The month goes first, so the block reads 2026, February 31. February 2026 has 28 days, since 2026 = 4 x 506 + 2. The overflow is 31 - 28 = 3 days, and SETTIME lands the clock on March 3, 2026. No alarm sounds and the operator is still typing. In a leap year the same keystroke would land on March 2, from 31 - 29 = 2.
With the staged screen, the operator sets V100 = 2026, V101 = 2, V102 = 20, V103 = 9, V104 = 12, V105 = 0, and nothing runs while the fields are edited. Accept is pressed. The checks pass: month 2 is inside 1 to 12, February 2026 ends at day 28 and 20 is under it, hour 9 is inside 0 to 23, minute 12 and second 0 are inside 0 to 59. The six moves fill UDT10, SETTIME runs once, and SDT0 reads February 20, 2026, 09:12:00.
How to check it worked
- Open a data view on V100 through V105 and type each field; the register tracks the entry.
- After one Accept, SDT0 and the system time read-back value show the staged time to the second.
- Hold Accept down. The edge trigger gives one execution per press, so SDT0 holds still after the first.
- Stage 2026, month 2, day 31 and press Accept. The rejected lamp lights and SDT0 keeps February 20. That is the test that shows the guard works.
- Restore the real time before the machine runs.
Keep the display path separate
The screen that shows time reads SDT0. The screen that sets time writes V100 through V105. Nothing crosses. When two panels share the PLC, give the write screen to one of them; one HMI reading the clock while another writes it lays out that split.
The panel's own clock-source page can push the panel's clock into Date and Time tags you choose, at each change or on a schedule you set. Those writes land in whatever registers they are pointed at, so aim them at registers nothing else owns. It still takes SETTIME to change SDT0.
For the readout, displaying date and 12-hour time on a text line keeps the formatting on the panel. A string built in the PLC with STRPRINT into SS memory also works when the clock object will not format the way you want.
Recommendation: build the staged screen: six entries on V100 through V105, the month-length check in front of the instruction, and one SETTIME fired by the Accept bit with Source Type Local. Reserve a write-on-change trigger for a locked supervisor screen that opens one field per edit, where each commit is a deliberate single change.
Questions
What does SETTIME do with February 31?
It normalizes the date instead of refusing it. February has 28 days in a common year, so 31 minus 28 leaves 3 days of overflow and the clock lands on March 3. In a leap year the month has 29 days, so the same entry lands on March 2. The clock moves and no error appears, which is why the ladder must reject an impossible date before the instruction runs.
Do I need to enter the day of week?
No. The block has a DayOfWeek member and the controller fills it from the date you set. Leave UDT10.DayOfWeek off the HMI screen and out of the staging registers; it is an output of the date, not an input to it.
Can the HMI clock-source synchronization set the PLC clock?
No. The panel's clock-source page writes the panel's own clock into the Date and Time tags you point it at, by default at each change. Those writes land in ordinary registers. Only the SETTIME instruction changes SDT0, so if you use the sync for anything, aim its tags at registers nothing else owns.
When should the Source Type be UTC instead of Local?
Set Source Type to Local when the operator types wall time, which is the normal case for a manual correction at the machine. Set it to UTC only when the staged values really are UTC, for example when another system hands you coordinated time. Getting it wrong shifts the clock by your full offset from UTC.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.