A PLC sets its own clock only when its CPU executes the documented time and date instructions; a direct write to the clock's registers leaves it unchanged. Stage each slave's target time about 1 minute ahead, pulse one trigger bit at the target instant, and resynchronize once a day.
When a plant runs time-based schedules on several PLCs, one wrong clock breaks the pattern quietly. Dampers, lighting and HVAC events fire at the wrong minute in one building while the other five behave. The fix is to let one master PLC publish the time and to make every slave set its own clock with the clock-setting instructions its CPU documents. Writing a slave's clock registers directly, whether from a PC data server or with a move rung, leaves the clock unchanged; clock registers only move when the CPU executes its time and date instructions. This page gives the full sequence: a staging block written ahead of the target instant, one trigger bit with a one-shot clear, the day-of-week calculation, and a once-a-day resync that holds six controllers within one communications cycle of each other.
Why won't a direct write to a PLC's clock registers work?
A PLC accepts a new date and time only through the clock-setting instructions its CPU executes. A write from a PC data server or a spreadsheet link into the clock's own registers leaves the clock unchanged while the network itself is healthy.
Treat that as design, not as a fault to chase. The clock's registers are not addressed like the rest of data memory, and both attempts fail the same way:
- A write into the clock registers from the plant's PC data server or a spreadsheet link changes nothing.
- A rung that moves values from ordinary data registers into the clock registers changes nothing either.
The values land only when the CPU executes the time and date instructions its reference documents, and those instructions read their operands from ordinary registers you control. That is the whole reason the scheme below stages values in temporary registers first.
Before you build any of this, check whether your controllers ship a time-synchronization service that keeps slave clocks aligned over the network automatically; how to synchronize ControlLogix and PowerFlex clocks walks through one such pairing. Controllers without that service need the staged-register method.
What does one master need to synchronize the other PLCs?
You need one master PLC designated as the time source, an agreed block of temporary registers plus one trigger bit in every slave, and each slave's documented time and date instructions wired to those registers. The network carries the values, but every slave sets its own clock.
- A master whose clock you trust. Set it by a method its own documentation supports and compare it against a known reference before every event. The operator-panel route in set a PLC clock from the operator panel for daylight saving time is that supported method, and it is also how the master gets corrected when daylight saving time changes.
- A staging block in every slave. Seven fields in registers both sides agree on: year, month, day, hour, minute, second, day of week.
- One trigger bit. The same address and the same meaning in every slave program.
- Clock-setting logic in every slave. When the trigger turns on, the slave executes its time and date instructions using the staged block.
- A completion indication per slave. Set by the slave's own logic after its instructions execute, so a synchronized report comes from the slave that acted.
Agree on the register map once and keep it identical in all six programs; a map that drifts per building is where this scheme fails.
How do the staged time and the trigger bit work?
Stage the complete target date and time in every slave's temporary registers about 1 minute ahead of the master's clock. Pulse the trigger bit at the exact target instant, and let each slave execute its own time and date instructions; the whole network lands within one communications cycle.
The 1 minute lead is a staging window, and its only job is to outlast the network. If one slave's register write takes one poll cycle, 250 ms in this example, staging six slaves takes 1.5 s and a 60 s window leaves 58.5 s of margin. Measure your own cycle time and keep the lead well above the total write time.
The skew comes from the last leg. Each slave reacts on the scan after it sees the trigger, so the clocks land between the target instant and the target instant plus one communications cycle. At a 250 ms cycle that is 250 ms of spread, which no schedule-level function can notice.
The sequence:
- Set the master's clock by a supported method and compare it against a known reference.
- Pick the target instant one staging lead ahead of the master's clock, sitting clear of any schedule boundary.
- Write all seven staged fields into the agreed registers in every slave and let the writes finish.
- When the trigger turns on, each slave executes its time instruction with the staged hour, minute and second and its date instruction with the staged date and day of week. In the instruction set this scheme follows, the two are named TIME and DATE; other CPU families name their equivalents differently.
- Clear the trigger once the slave has executed, so the next event arrives as a fresh on-edge. A bit that stays high is a permanent enable, and the clocks get rewritten on every scan.
- Read back the date, time and day-of-week field on each slave.
One safety note: a clock jump can skip or repeat a time-based interval. Run the first live event on equipment you are watching, with schedules that cannot tolerate a skip or repeat held in bypass.
Does the day of week go with the date?
Send the day-of-week value whenever any slave program branches on it, because the date instruction writes the whole calendar record including that field. Compute the number from the date with Zeller's congruence so no operator maintains it by hand every week.
The formula:
h = (q + floor(13 * (m + 1) / 5) + K + floor(K / 4) + floor(J / 4) + 5 * J) mod 7
q is the day of the month, m is the month with March as 3, K is the year within its century and J is the century. January and February count as months 13 and 14 of the previous year. The result runs 0 = Saturday through 6 = Friday. Shift it into whatever numbering your CPU's date instruction expects, and prove the shift on one date you know before the first automatic event: a PLC that wants 1 = Sunday through 7 = Saturday takes a different offset from one that wants 0 = Sunday.
How often should the master resynchronize the slaves?
Resynchronize once a day and again after any reset of the master's clock, because independent clocks drift apart: a quartz real-time clock at 50 parts per million gains or loses about 4.3 seconds per day, from 86,400 seconds multiplied by 0.00005.
Two slaves at opposite ends of that tolerance drift 8.6 seconds apart in one day, which is enough for two buildings to disagree about a 06:00 start by nearly nine seconds. The daily event resets the spread to at most one communications cycle, so once a day is the right interval for schedule-level work. Tighten it only for an application that compares timestamps across controllers. The 50 parts per million is the usual tolerance class for a quartz clock, not a rating for your CPU; the read-back after each event shows what your own clocks do.
Once the PLC clocks agree, the HMI and trend screens can take their time from the master too; the pattern is in set an HMI clock from the PLC and read trend axes in time.
Recommendation: put the clock-setting logic in every slave, keep one master, stage the target 1 minute ahead, pulse and clear one trigger bit, and rerun the event once a day and after every master reset. That combination holds a six-PLC network within one communications cycle of one standard.
What does a worked example look like with six PLCs?
Six building controllers stage 09:48:00 on 15 July 2026 while the master reads 09:47:00, the master pulses the trigger at 09:48:00, and all six clocks read the same second within one 250 ms poll cycle, so every building's 09:48 schedule starts together.
Take the 250 ms poll cycle as the example network's update time and 15 July 2026 as the example date; substitute your own measured numbers.
- The master's clock is verified at 09:47:00, so the target instant is 09:48:00, exactly 60 s ahead.
- The seven staged fields are year 2026, month 7, day 15, hour 9, minute 48, second 0, and the day-of-week number.
- Day of week: q = 15, m = 7, K = 26, J = 20, so
h = (15 + floor(13 * 8 / 5) + 26 + floor(26 / 4) + floor(20 / 4) + 5 * 20) mod 7 = (15 + 20 + 26 + 6 + 5 + 100) mod 7 = 172 mod 7 = 4. With 0 = Saturday, h = 4 is Wednesday, and 15 July 2026 is a Wednesday, which confirms the formula. If the CPU wants 0 = Sunday, stage 3 instead. - Six register writes at 250 ms each finish by 09:47:01.5, leaving 58.5 s of the 60 s window unused.
- At 09:48:00 the master pulses the trigger, and each slave executes its instructions on the scan after it sees the bit. The last slave lands by 09:48:00.25.
- Read-back shows six clocks at 09:48:00, the trigger clear and the completion bits set. The spread across the plant is 250 ms, against the 8.6 s the clocks had drifted apart since the previous day's event.
How do you check that every clock actually changed?
Trigger one slave first and read its clock back before you touch the other five: the staged values must already be present when the trigger arrives, the trigger must clear, and the read-back date and time must match the staged target exactly.
| Check | What you expect |
|---|---|
| Staged registers before the trigger | All seven fields present and stable in each slave ahead of the target instant |
| Trigger after execution | The bit low again, so the next event is a fresh on-edge |
| Read-back | Year through seconds plus day of week matching the staged values on every slave |
| Completion bits | Set by each slave's own logic, so a synchronized report reflects execution, not just the pulse |
| Measured spread | All clocks read together land within one communications cycle |
| A slave that was offline | Old clock until the next event; read it back after the link returns and check the reconnect path in make a Modbus master reconnect after a slave outage |
Keep the boundary straight at the end: the PLC clocks are the plant's time source, while a wall screen playing scheduled content is a separate content job, so treat a shop-floor notice or andon display as its own decision, not as another slave in this scheme.
Questions
Does every PLC use TIME and DATE instructions for this?
TIME and DATE are the names in the instruction set this scheme follows, and other families name their equivalents differently. What stays constant is the rule: the staging block is ordinary writable memory, the clock is set only by the CPU's own instruction, and the operand order comes from the reference for that exact model. Verify the operand list on one test controller before you copy the rung into the other five.
What happens to a slave that misses the trigger?
It keeps its previous clock until the next event, so the damage is bounded by one day of drift. Keep the trigger as a level with a clean on-edge and stage fresh values for every event; then a slave that was offline catches up at the next daily resynchronization instead of staying out of step. Read its clock back after the link returns to confirm it saw the event.
Can a PC or the HMI be the master instead of a PLC?
Yes, as long as it follows the same rule: write the staged values to the slaves' temporary registers and pulse the trigger bit, and never write the clock registers directly. A PLC master fires the trigger from a clock the PLC logic already sees every scan; a PC master gives you one place to correct the site's time for daylight saving before it is staged.
How does daylight saving time fit into a daily resynchronization?
Change the master's clock on the morning of the switch, then trigger one extra synchronization event right after the change. Slaves only move when a trigger arrives, so without that extra event every building runs an hour off until the next scheduled resync. Because the event also rewrites the date and day-of-week fields, the weekday logic stays correct after the overnight change.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.