Share one operator panel clock with multiple PLCs

Why does the panel clock write reach only one PLC?

Because Write to PLC Tags is a single-destination feature. The panel help documents it as writing the values from the panel's own real-time clock to tags configured in one controller, and this job needs five controllers fed from that one clock. The setting lives under Setup > Clock Source in the panel project. It solves the one-controller case well: for a single PLC, that write plus a time compare is the whole job, and scheduling PLC outputs by day and time from an HMI panel walks through it.

Count a second controller and the design breaks, because the write holds one destination and nothing sends the values onward. The controllers past the first keep comparing against whatever already sits in their registers, usually zeros, so a schedule built on them never fires. Distribution therefore moves out of the clock-write setting and into an event that writes to each controller in turn, which is what the Event Manager's Tag Copy action exists for.

What do you need before you start?

You need the panel project software once, a working link from the panel to every controller, six free registers in each controller, the release and relock times agreed per door, and panel power from an outlet adapter or a DIN-rail DC supply. Count the registers before opening the project; each controller holds six panel-visible values.

Six registers per controller across five controllers is 30 registers, which even a small controller has spare. The freshness logic in the stale-clock section lives in controller memory only, as a stored minute, a miss counter and a fault bit, so it needs no panel-visible register.

Match each destination tag's data width to the panel tag in the driver settings. Take register addresses from each controller's own manual, because the five need not share a model or an address map. The same copy runs over serial when the plant has no Ethernet to the panel; connecting multiple PLCs to one HMI over an RS-485 network covers that wiring. A DIN-rail DC supply keeps the panel's power wiring inside the cabinet instead of an outlet on the wall.

How do you copy the panel clock into all five PLCs every minute?

Create one timed event in the panel's Event Manager that fires on the minute system tag SYS CLOCKMIN and runs a Tag Copy action per controller, so the received hour and minute refresh in all five controllers within the same minute. Work through the project in this order:

1. Open the panel project and find the two tags the panel publishes from its own real-time clock, the running hour and minute. Write down their exact names and data width from the tag table.
2. In each controller's driver, map two destination tags, CLK_HR and CLK_MIN, to that controller's first two free registers. Take the addresses from that controller's manual, not from its neighbour's.
3. Switch the built-in Write to PLC Tags under Setup > Clock Source off, so the copy event is the single writer for all five controllers and every register has one writer.
4. Create the event. Trigger it on SYS CLOCKMIN, which fires once per minute, and add five Tag Copy actions, one per controller: panel hour to CLK_HR, panel minute to CLK_MIN. A documented event carries any of 11 actions, so five copies fit in one event with room to spare.
5. Build the schedule screen: four numeric-entry objects per controller writing REL_HR, REL_MIN, LOCK_HR and LOCK_MIN, labelled with the door number, which makes 20 entry fields across five doors. The objects write registers; the Event Manager table never changes at runtime, so no screen edits events and none needs to.
6. If the panel can fire an event from a screen button, add one that runs the same copies once, useful right after a clock correction; panels without that ability catch up at the next minute tick anyway.

How does each PLC decide when its door should release?

The controller reduces both its received clock and its operator setpoints to minutes since midnight, compares them with two integer tests, and follows one written convention for midnight: a release time later in the day than the relock time means the window crosses midnight. A day holds 24 × 60 = 1440 minutes, so t = CLK_HR × 60 + CLK_MIN lands between 0 and 1439, and rel = REL_HR × 60 + REL_MIN and lock = LOCK_HR × 60 + LOCK_MIN reduce the same way. Then apply the convention:

• rel < lock: the window sits inside one day; release when rel ≤ t < lock.
• rel > lock: the window crosses midnight; release when t ≥ rel or t < lock.
• rel = lock: an undefined window; hold the output off, which keeps the door locked all day.

The equal case fails to the locked side on purpose: an operator who types the same time twice has not defined a window, and the safe state for a public door is locked. The compare runs in the controller, so the panel screen mirrors the setpoints and the received time while the output that moves the door lives in the controller. The schedule moves the locked side only; free-exit hardware must let anyone leave from inside with or without power, exactly as the fire code governing the building requires.

How do you catch a stale clock before it runs the schedule?

Give each controller a self-resetting 60-second timer and let it judge freshness. If the received minute value has not changed after two timer periods, about two minutes, the controller raises a STALE fault and holds its door output at locked until fresh time returns. The detection works because the received minute changes every 60 seconds whenever copies are flowing. A minute that sits still through two periods means the writes stopped, whether the cause is a pulled patch lead, a powered-down panel or a dead switch.

Wire STALE to an annunciator or a panel alarm so the shift sees it, and let the schedule resume within one minute of fresh time arriving. The momentary release button stays independent of this logic, so a controlled release still works while the fault is active. The wider question of what schedules should do while the panel is down has its own walk-through: keeping PLC schedules running when the HMI panel is offline.

What does the example look like with five PLCs and five doors?

In this scenario an 8-inch panel serves five controllers over Ethernet, doors one through four release at 07:00 and relock at 18:00, door five releases at 19:00 and relocks at 06:00, and the panel clock reads 14:37. At the 14:37 tick, SYS CLOCKMIN fires and controller 3 receives CLK_HR = 14 and CLK_MIN = 37, so t = 14 × 60 + 37 = 840 + 37 = 877 minutes since midnight.

The boundary behaves too: at 18:00, t = 18 × 60 = 1080, and 420 ≤ 1080 < 1080 fails because the upper test is strict, so doors one through four relock at 18:00 sharp, not a minute later. The trigger period bounds the error: any transition lands within about 60 seconds of its setpoint.

Freshness at the same tick: controller 3's timer watched CLK_MIN move from 36 to 37, so the miss counter stays at zero and no fault is raised. Bookkeeping for the whole site: 6 registers × 5 controllers = 30 registers, and 5 Tag Copy actions sit inside the 11-action limit of one event.

How do you check the copies and schedule before handoff?

Check the chain in this order: watch all five controllers receive the same minute within one minute of a panel clock change, edit one setpoint and confirm only its own controller moved, then test the two midnight windows and the cable-out fault before anyone relies on the doors.

1. Set the panel clock to a known minute, then read CLK_HR and CLK_MIN in all five controllers within the following 60 seconds. Five controllers means five matching readings; a mismatch points at a wrong destination in the copy list.
2. Change one setpoint on the schedule screen, door 5's relock from 06:00 to 06:30, and confirm only controller 5's LOCK_MIN moved while the other 29 registers held their values.
3. Set a window one minute ahead of the test time and watch the output flip within 60 seconds of the setpoint, then watch it flip back at the relock minute.
4. Run a midnight window in real time: release 23:58, relock 00:05, and confirm the output turns on at 23:58 and off shortly after 00:05 under the rel > lock rule.
5. Pull the panel's Ethernet lead at a moment when nobody depends on the schedule. Every controller should raise STALE within about two minutes and hold its door locked; restore the lead and confirm each schedule resumes within the next minute.
6. Press the momentary release once with the schedule output off and confirm the door still releases, because the exit path must never depend on the clock logic.

When is the panel the wrong time source?

Choose a different time source when the schedule must survive a dead panel or land within seconds: a real-time clock module in each controller, or one clock-equipped master controller feeding the others, costs little and removes the panel from the critical path.

The whole schedule depends on one panel, one link and one event. A technician who powers the panel down for a screen swap takes every schedule down with it; the locked-doors fault is the correct response, but some sites need the schedule to ride through that outage. Accuracy has a bound too: a once-per-minute trigger puts every transition within about 60 seconds of its setpoint, and a door that must move within seconds of 18:00 needs a clock the controller itself holds.

Because the controllers in the main design keep no clock, a daylight saving change touches only the panel clock; where a controller does hold its own clock, setting a PLC clock from the operator panel for daylight saving time covers that job.

Recommendation: Use the once-per-minute Tag Copy event for up to ten clock-less controllers on one Ethernet link, keep the four schedule registers and the compare inside each controller, and fit a real-time clock module to any controller whose door must change within seconds of its setpoint or keep its schedule through a panel outage.

Questions