How often should you service a PLC? A practical UK guide

PLCs are, quietly, the most trusted piece of kit in a modern factory. They sit in the panel, blink patiently, and rarely ask for anything. That's exactly the problem. Because they don't announce themselves — no belt to break, no seal to leak — they end up at the very bottom of the PPM list. Then, one Sunday night, something drops, no one has the program, and the works manager has an interesting Monday.

This article is about setting a sensible, risk-based service interval for the PLCs on your site, and about what "servicing" a PLC actually looks like in practice. Nothing exotic — just the discipline that separates a controller that runs for fifteen years from one that drops out at year seven.

What "servicing a PLC" actually means

A PLC service is not usually about the CPU itself. Modern industrial processors are extremely reliable. What is being maintained is the installation around the PLC and the software running on it. A reasonable service covers six areas:

• Battery. Where the platform still uses a backup battery for retentive memory or the real-time clock, check the voltage and status flag and replace on the manufacturer's recommended cycle — typically several years but earlier if any low-battery warning has been logged.
• Firmware and memory card. Verify firmware version against the vendor's supported baseline. Read the memory card into the engineering workstation and confirm it matches the master program on file. If it doesn't match, someone has changed the program online without updating the master — and you need to know.
• Program backups. Take a fresh backup of the running program, comments and symbols. Test the restore on a spare CPU or in the vendor's emulator. An untested backup is not a backup.
• I/O terminations. Torque check terminal blocks and IO cards where safe to do so. Loose terminations are a leading cause of intermittent, hard-to-find faults on live systems. Thermal imaging of the panel is the safer non-invasive equivalent.
• Communications. Check network health for the PLC's buses — Ethernet/IP, Profinet, Modbus TCP, Modbus RTU, CANopen or whatever the platform uses. Look for CRC errors, dropped frames, duplicate IP addresses, and drift on subordinate device counts.
• Environment. Panel cooling fans and filters clean and running. Cabinet seals intact. Ambient temperature and humidity inside the range on the CPU datasheet. Dust — especially conductive or damp dust — cleaned out of the panel with the appropriate method for a live cabinet.

Setting a sensible interval

There is no single "right" frequency for servicing a PLC — the Electricity at Work Regulations 1989 impose a maintenance duty without prescribing intervals, and vendor recommendations vary by product. Interval should be set based on the risk the controller carries: how critical is what it's doing, and how bad is a stop?

A workable framework for most sites looks like this:

• Critical PLC (production line, safety interlock, batching, refrigeration): quarterly light-touch (visual, comms health, HMI walkthrough, thermographic scan of panel) plus an annual deep service.
• Important PLC (utility plant, back-of-house services): annual deep service plus a mid-year non-invasive check.
• Standalone / low-consequence PLC (single-machine controllers, ancillary equipment): annual visit at the same time as the machine itself is serviced.

Whichever cadence you pick, write it into the site PPM plan alongside the other assets — don't treat controllers as an electrical-department afterthought.

Signs your PLC needs unplanned attention

Between planned services, keep an eye out for the symptoms that precede a serious failure. Any of the following justifies pulling the interval forward:

• Recurring unexplained trips or resets — especially at consistent times of day
• HMIs losing comms to the PLC intermittently
• Sluggish or drifting scan times
• Any battery warning LED or diagnostic bit set
• Hot terminations or panel components on a thermographic sweep
• Nobody on site is confident what version of the program is running
• Changes have been made online without an updated master backup

The last two are software issues rather than hardware ones, but they cause the most expensive Sundays.

Program governance — the least glamorous, biggest win

Most of the pain we see with older PLCs on client sites is not the hardware — it's that the program has drifted from any recognisable master. Online tweaks made during a breakdown never made it back into source control. Comments have been stripped. Symbol names are out of date. Nobody remembers why a bit is forced.

Two simple governance rules stop this in its tracks:

1. Every change — however small, however urgent — is committed to the source of truth within 24 hours of the visit. The source of truth can be a shared drive, a version-controlled repository or the Operations Portal — but there is one, and it is the one everyone trusts.
2. At every service visit, the running program on the PLC is compared against the source-of-truth master. Any deltas are investigated and either promoted to the master or backed out. No exceptions.

Obsolescence — plan for it, don't be surprised by it

A PLC platform typically enjoys a long support life, but nothing runs forever. When the vendor announces end-of-life, work with your controls engineer to build a migration plan on a three- to five-year horizon: parts availability, program conversion effort, downtime window, and — often overlooked — the state of the surrounding I/O and wiring. Retrofitting a modern CPU into a panel where half the terminations are original 1990s work is rarely a straight swap.

The takeaway

A PLC that's been serviced — hardware, firmware and program — gives you predictable behaviour year after year. A PLC that has been left alone will eventually fail in the way you least want it to. Put the interval in the PPM plan, put the program in one trusted place, and treat the controller with the same discipline you already apply to the motors and pumps around it.

A short checklist for the next service visit

If you're booking a PLC service and want a workable brief to send to the engineer, the list below is a solid starting point. It covers the essentials without adding busy-work.

1. Take a fresh source-code and configuration backup before touching anything. Verify the file opens in the engineering tool.
2. Compare the running program against the source-of-truth master. Investigate and document any differences.
3. Read the CPU diagnostic buffer / fault log. Address anything logged since the last visit.
4. Check firmware version against the vendor's supported baseline; escalate if any component is out of support.
5. Inspect the battery and memory card status; replace on manufacturer schedule.
6. Torque-check accessible terminations on the PLC and remote I/O racks; thermographic scan of the panel where safe to do so.
7. Verify comms health — port statistics, error counters, subordinate device counts — for every network the controller is on.
8. Test panel cooling: filters clean, fans operating, ambient temperature within CPU datasheet limits.
9. Walk through the HMI: every screen, every alarm, every trend. Confirm nothing is showing a permanent warning that's become "normal".
10. Update the master backup, tag it with date, version and engineer, and store it in the agreed source of truth. Log the visit.