Put the weekly lighting schedule in each PLC's own clock and logic, and let the central HMI panel only observe and override with writes that time out in the PLC. Budget the panel's poll rate across all eight PLCs and group tags into block reads, so local switches and scheduled lighting keep working with the panel unplugged.
The schedule belongs in the PLC, not in the panel. Put each area's weekly lighting schedule in the PLC that drives those lights. Keep the central HMI panel as a supervisor that observes and overrides. Budget the panel's poll rate across all eight PLCs instead of one. Done that way, a dead panel costs you visibility and overrides and nothing else. The local switches still switch and every light still follows its schedule. This article covers where each function lives, what keeps local switching working, how to size the poll traffic, how to keep eight PLC clocks honest, a worked example for a 300,000 sq ft plant, and what to ask for before you buy. Lighting is the worked case; ventilation and heating follow the same split.
Where should the lighting schedule live so it survives a dead panel?
Each schedule belongs in the PLC that drives its own lights. Write it against that PLC's real-time clock, with the central panel writing only overrides. Then all eight PLCs keep switching on time with the panel powered off or unplugged from the network.
The test for every function in the system is one question: does it still work with the panel unplugged? Anything you answer no to on purpose goes on the handover sheet, so the crew knows exactly what stops when the panel stops. Safety sits inside that test: keep code-required circuits such as egress and emergency lighting on their own code-compliant controls, with the automation running on top, never as their only path.
| Function | Where it lives | With the panel down |
|---|---|---|
| Local switch to light | the PLC serving that area | still works |
| Weekly on/off schedule | the same PLC's clock and logic | still runs |
| Operator override | a bit the panel writes, timed out in the PLC | lapses when its timer expires |
| Overview and alarm history | the central panel | blind until the panel returns |
| Programming changes | a central PC, connected on demand | not needed for running |
That split reframes the purchase: you are not shopping for a bigger panel, you are assigning each function to the device that still holds it when the panel is gone.
What keeps local wall switches working when the panel is offline?
Program each switch into the logic of the PLC that drives its lights. Rank that switch above any schedule or panel command, because a switch whose path runs through a bit that exists only in the panel is a switch that dies with the panel.
Give every PLC the same priority ladder: the local switch first, a timed override bit second, the weekly schedule third. Write the override with a PLC-side timer, 2 hours for a typical hold, so a stale command expires even when nobody has noticed the panel went down. If your PLC exposes a per-connection status bit, use it to fall back to schedule plus local switches when communications drop; if it does not, the timers already cover the case. Then test with the cable pulled: disconnect the panel during a working shift, operate every switch type, and confirm each light answers at the PLC terminals with the panel still dark.
How do you budget the poll rate across eight PLCs instead of one?
Pick the refresh each screen really needs, multiply by the PLC count, and read tags as grouped blocks. For lighting, 2 s per PLC is ample, so one block read every 2 s from each of eight PLCs is 4 requests per second plant-wide.
Three things move that number. Hidden screens: some panel software keeps polling tags on screens nobody is viewing, so take the worst case from the manual before you trust a bench test. Extra readers: a second panel, a SCADA node and the programming laptop's online view each add their own polls on top. Single-register reads: reading 24 contiguous status registers as one block replaces 24 separate requests, so the request count falls by the block length.
What a request costs: on a switched 100 Mbit/s network a read returns in a few to a few tens of milliseconds, and the PLC's scan and connection handling do most of that; the wire is not the limit, the request count is.
Speed targets: lighting states change on the scale of minutes, so 2 to 5 s reads as live. A common integrator target for watched process values is under 1 s, ideally under 0.5 s, and you pay that rate only where an operator is actively watching.
Routing: multiple routers add hops, so test reachability from the panel's location with all eight PLCs online. One PLC that alone will not answer is a routing or addressing fault before it is a load problem. Map the panel's tags per device while you are at it: the per-device tag setup for one panel serving several PLCs is worked through in Point one HMI panel at multiple PLCs with per-device tags.
The same arithmetic covers polling a separate PLC at each site over Ethernet when one master station watches remote sites.
Which clock do the PLC schedules follow, and how do you keep it honest?
Each PLC follows its own real-time clock. Correct every PLC clock against a phone or the panel once a month and before each daylight-saving change. A plain crystal's tens of parts per million of error is about a minute a month, 12 minutes of slip in a year.
Each PLC family keeps its clock in a fixed block of system registers, and the manual lists the addresses. Exercise the schedule logic on a test output before it touches real circuits; the classic first test is an output that runs Monday to Friday from noon to 1 PM. Daylight saving moves every edge by 1 hour, twice a year: correct the clocks by hand on those weekends, or run a daylight-saving routine in the logic and test it on a test output the same way. For the by-hand path, setting a PLC clock from the operator panel for daylight saving time shows the correction from the panel. Clock retention across a power cut depends on the PLC's battery or backup capacitor, and the manual lists the time it buys; after an outage longer than that, check the clock before trusting a single scheduled switch.
What happens to the outputs when the panel or network fails?
Whatever the PLC program defines: a communications loss moves no output unless the logic moves it. Write the fallback for each function in the PLC and prove it with the panel's cable pulled during a shift while someone watches the zone lights.
Write and code one line per function:
- Schedule: it keeps running, because it lives in the PLC; that is the point of the split.
- Overrides: they hold until their PLC-side timer expires, 2 hours in this design, or they clear on communications loss; never leave one latched without a timer.
- Local switches: they keep working, per the priority ladder above.
- Indication: the panel's values go stale, so put the panel software's per-device communication status flag on every screen, and an operator must be able to tell a commanded state from a confirmed PLC state.
- The cost, written on the handover sheet: overrides and the overview screens, nothing else.
What does the design look like in a worked example?
A 300,000 sq ft plant with eight small PLCs and one central panel runs its lighting on 4 block reads per second, and a panel failure costs it nothing but overrides and the overview screens.
Scenario: eight PLCs, one per area of the plant, each holding 16 lighting zones and 8 switch inputs mapped as one contiguous block of 24 status registers. Each PLC also holds the override bits the panel writes, each timed out in the PLC after 2 hours. The panel shows three area screens plus an overview, and 2 s was chosen as the status refresh because lighting states change on the scale of minutes.
Poll arithmetic: one block read per PLC every 2 s is 0.5 reads per second per PLC, and 8 PLCs at 0.5 reads per second is 4 reads per second for the plant. At about 10 ms of PLC service per read on the switched plant LAN, each PLC spends about 5 ms of every second answering the panel. Read the same 24 registers one at a time and the same refresh turns ugly: 24 reads every 2 s is 12 reads per second per PLC, 96 reads per second plant-wide, about 120 ms of each PLC's second spent answering the panel. Block grouping is the whole difference.
Schedules and clocks: each PLC holds its own weekly grid, the offices at 06:00 to 18:00 on weekdays, and every grid was first exercised on a test output that ran Monday to Friday from noon to 1 PM. Clocks are checked against the panel on the first Monday of each month, because a minute a month of drift is 12 minutes a year of edge slip.
Failure test: at 14:05 the panel's network cable comes out. The lights keep following their PLC schedules, the local switches keep switching, the panel's screens go stale with the communication status flag showing, and any latched override runs out on its 2-hour PLC timer. Plug the panel back in and the overrides work again. The failure cost the plant its overview and its overrides and nothing else.
Should the maintenance office also get a wall board for the schedule?
Yes, if staff keep asking what is running and when. But hang a signage display, not a second HMI: a wall screen that plays a weekly schedule image from its own memory card offline adds nothing to the PLC network and needs no poll budget at all.
That board is a notice board, not a control point. Choose one that plays its own files offline from a memory card or USB stick, with the software included and no subscription, so a schedule change is a new image loaded when the schedule changes. Mounting and power are the same job as for any wall screen, and the parts live on our accessories page: a low-profile VESA wall bracket, a wall-power adapter for a desk or counter outlet, and a 24 V DC DIN-rail supply for a low-voltage feed from a cabinet.
When should the schedule live in the panel instead?
Only when schedules are edited daily by non-engineers from one desk and must never disagree between areas. Then one PLC becomes the schedule master and pushes times to the others, and a dead master or network pauses scheduled changes until it is back.
That trade buys a single point of editing and pays with a single point of failure. Lighting schedules in most plants change a few times a year, so per-PLC schedules edited from the central PC win. When areas must move together, for an energy curtailment event for example, the master pattern earns its keep, and the arrangement with a master PLC coordinating several panels and many PLCs is laid out in Two HMI panels polling many PLCs: use a master PLC.
What should you ask for before you commit to a panel?
Four answers from the panel and PLC manuals decide the design: whether screens poll tags nobody is viewing, whether you can set a poll interval per device, whether the driver groups contiguous registers into block reads, and how long the PLC clock survives without power.
From the panel manual
- a poll interval you can set per device, so the lighting screens run at 2 s and a watched screen can run faster
- whether hidden screens keep polling, and how to stop it
- grouping of contiguous registers into block reads
- a per-device communication status flag you can put on screen
From the PLC manual
- the clock's register block and its backup time on battery or capacitor
- which registers and schedules hold through a power cycle
From the network
- an address and a route checked from the panel's location, with all eight online and every screen loaded
Get those four answers in writing and the design closes; without them you are sizing the network from a bench test, and the bench has one PLC where the plant has eight.
Recommendation: put the full weekly schedule and every local switch in each PLC, keep the panel to observation and overrides with PLC-side timers, poll each PLC as one grouped block read every 2 s for lighting, and reserve sub-1 s refresh for values an operator is actively watching; then prove the design by pulling the panel's network cable during a working shift. Move the schedule into a master PLC only if non-engineers will edit schedules daily and the areas must never disagree.
Questions
Does the central panel's clock still matter once every PLC holds its own schedule?
Yes, as a reference and a time-stamp source, not as a schedule source. The panel clock time-stamps alarms and operator actions, and it is the reference you correct the PLC clocks against on the monthly check. Keep every clock within about a minute of the panel clock so the panel's logs agree with the switching done by the PLCs, and write down which clock each log uses.
How fast should the panel poll heating and ventilation points instead of lighting?
Space temperature moves over tens of minutes, so 30 to 60 s per PLC is plenty and keeps the poll budget small. A point you command, such as a damper or a fan start, wants its feedback confirmed faster, on the order of 1 to 2 s, so the operator sees the result. Give every commanded point a status bit and show it on screen.
What happens to the schedules after a power failure?
Each PLC resumes from its own clock and its retentive memory, so the schedule survives if the clock did. How long the clock holds without power depends on the PLC's battery or backup capacitor, and the manual lists that time. After an outage longer than that, verify the clock before trusting the schedule edges, because a PLC that rebooted with a default clock switches lights at the wrong times until it is corrected.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.