A control-cabinet checklist for PLC identification

A cabinet audit is one planned photo pass through a controller cabinet, done while everything still runs. The goal is an evidence pack that answers identification questions years later, without a second visit. Three layers carry the work: the controller set itself, the context around it, and the storage path that keeps everything findable. Each layer feeds the next one, so a weak layer wastes the effort put into the others.

Enlarged system diagram

×

Read left to right: both photo layers are collected on the same visit and only become useful once the pack is stored where others can find it.

The controller set means more than the CPU. It includes the power supply, every I/O module, and their order in the rack. The context layer ties those electronics to a real process: the machine or line they control, the network they sit on, and the cabling that connects them. The storage layer then decides whether anyone can retrieve the pack on the day it matters.

Be clear about what an audit is not. It does not diagnose a fault, confirm compatibility, or replace a project backup. It documents identity and arrangement. That boundary matters, because a pack built to prove identity stays useful for years, while a pack padded with unrelated detail hides the photos that matter.

Timing decides how much an audit costs. Run it during planned maintenance or a window you control, never in the middle of a stoppage, because a rushed pass produces exactly the blurred and partial photos the audit exists to prevent. Repeat the pass after any reorganization, module swap, or rewiring, since a pack that documents the cabinet of two years ago misleads more than it helps. A one-page note of what changed between passes keeps the history readable.

The controller set is documented with two kinds of shots: one clear photo of each CPU nameplate and one of the label on every I/O module. A nameplate is the printed plate carrying the order number and version marking, and each module carries its own. Check every image for focus before you close the door, because a blurred label photo is indistinguishable from no photo until someone needs it during a stoppage.

Enlarged system diagram

×

Every shot passes the same check: if a label is not legible, retake it before the cabinet closes, not after.

Photograph the rack as a whole so module order and slot positions stay visible. A rack overview plus per-module label shots makes the set reconstructable later. That matters because the same reference can appear twice in one rack, and the project may address each occurrence differently. Slot positions also let a reviewer tell the CPU from its power supply and its I/O without asking.

Do not stop at the module faces. On many Siemens layouts the full order number is repeated on a sticker inside a door or on the module side, and those secondary labels often outlast the front faces. Wear patterns differ between faces and edges, so the second label often carries blocks the first has lost.

Where a label is worn, take a second shot at an angle: raking light often recovers print that a straight-on shot misses. A dry cloth removes film without risking the print. If a module cannot be photographed clearly in place, note its position and photograph it during planned maintenance instead of forcing the cabinet open.

The context layer answers a different question than the labels do: which process do these electronics control? Capture the power supply, the network switch, and any labels that name the machine or the line. The machine name is what makes the pack findable when it is needed, and a set of perfect rack photos with no machine identification is an orphan archive.

Enlarged system diagram

×

Each context photo type serves one purpose. Arrows show which question a photo answers, not any physical connection.

Photograph the network side while everything is still connected: the switch face with cables in place, the cable labels, and the ports used by the CPU. Port assignments are the first thing lost after a disconnection and among the most expensive to recover by tracing. Capture anything that will change, because a photo taken after rewiring documents the new state, not the one the project expects.

The supply type visible in the photos also cross-checks the variant block you read on the CPU, so the two layers confirm each other. Photograph wiring ducts and terminal strips around the controller only where they clarify connections. A useful rule: one extra photo per connection you would not want to trace twice. Restraint is part of the skill, because an oversized pack hides the photos that matter.

Some context belongs in the pack by omission. The spare-parts shelf, the neighboring cabinets, and the office paperwork are not evidence about this controller, and photographing them buries the useful shots under volume. If a neighboring cabinet feeds the same machine, note that fact in one line rather than photographing the whole rack. The pack should grow at the edges of the controller, where its connections and its name live, and stop there.

Evidence that nobody can find helps no one during a stoppage, so the discovery path is part of the deliverable. Store the photos with the machine name, the date, and a one-line note on why the audit was done. A shared folder structure or a maintenance system entry both work, as long as someone other than the photographer can find them. Record who took the photos too, so open questions can be routed to the person who saw the cabinet.

Enlarged system diagram

×

Two inputs reach the store: how the files are named and what the note says. Both decide whether retrieval works years later.

Name the files so they sort and read without opening them, for example by machine, cabinet, and module position. A folder of camera-default names forces the next person to open every file to learn what it shows. That friction is small per photo and decisive in total, and it is enough to make a pack go unused in practice.

The test is simple: hand the storage location to a colleague and ask them to find the photo of the third module from the left. If they can do it without calling you, the pack will be used. If they cannot, no amount of good photography will save the audit.

A pack built this way supports a reference request directly. The person reading it can confirm the reference, the family, the rack layout, and the network context without asking for more photos, and the request moves to a reviewed decision in one cycle. That outcome is the whole point of the audit: evidence that works without a second cabinet visit.

Enlarged system diagram

×

The pack and its limits travel together. Stating what the evidence does not prove keeps the review honest.

The pack proves identity and arrangement, nothing more. It does not show why a machine stopped, whether a replacement will accept the project, or what a supplier can deliver. Those questions need their own evidence, and a pack that claims more than it contains creates false confidence on both sides of a request.

Facts also age. A pack from three years ago describes the cabinet as it was, so re-date anything that changed and note what was re-verified. That habit is the difference between an archive and a working tool: the archive is stored, the working tool is maintained. Write the three checks into the review note itself, so the re-verification happens even when the person opening the pack is not the person who built it.

Audit quality decays quietly, so put a review date on the pack. When the plan is next reviewed, or the machine is next serviced, check three things: the reference still matches the unit in the rack, the network photos still match the cabling, and the storage location still resolves. Ten minutes of re-verification keeps the pack a working tool. Skipping it is how working tools turn back into archives.

• Photograph every nameplate and module label, plus a whole-rack overview that preserves slot order.
• Capture the switch, cable labels, power supply, and machine labeling while everything is connected.
• Store the pack with machine name and date where someone other than the photographer can find it.
• Name files by machine, cabinet, and position so the pack reads without opening every photo.

• the PLC and CPU topic hub
• the nameplate identification walkthrough
• the network context article