How to check a PLC CPU successor reference

A successor check compares two units: the CPU installed in your cabinet and the candidate that could replace it. Swapping a CPU for its successor sounds simple until the first wiring mismatch. The comparison runs between order number blocks and recorded facts, not between marketing names or catalog pages, and every item gets written as a pair: what the installed unit has, what the successor has.

Enlarged system diagram

×

Both units feed the same list of pairs. A pair without a source is an assumption, not a comparison.

The written pairs are the deliverable. A comparison that lives in someone's head cannot be reviewed, and a successor decision is exactly the kind of decision a second person should be able to check. Written pairs also survive staff changes, because machines that run for decades outlive the people who commissioned them.

This section walks the comparison in the order the risks appear: first the hardware that changes cabinet work, then the firmware that gates the project, then the bindings that no nameplate shows. A photo of each unit next to its written pair makes the check even harder to dispute. The order of the list is also the order of cost: hardware changes are visible first, bindings surface last.

Know where each side of the pair comes from. The installed unit is described by your own record: nameplate photos, an engineering-tool read, and the rack position. The successor is described by manufacturer documentation: the equipment manual and the published technical data. A pair that mixes a measured fact with a remembered one is weaker than it looks, so mark the source on every line and keep the two sides distinguishable.

Start with the facts that change cabinet work: the power supply input, the integrated output stage, and the integrated I/O counts decide whether existing wiring survives the swap. A CPU 1214C DC/DC/DC (6ES7214-1AG40-0XB0) feeds 24 V transistor outputs into its terminal rows. Its AC/DC/relay sibling switches loads through relays on a different supply input. So the real comparison runs between order number blocks, not between marketing names.

Enlarged system diagram

×

Each hardware line ends in a work estimate, not a verdict. This is a functional comparison, not a wiring diagram.

Mounting and network layout belong on the same list. Moving from a compact CPU 1214C with one PROFINET port to a CPU with two ports changes what the cabinet can connect without extra hardware. Moving to a different form factor, such as an ET 200SP CPU 1510SP-1 PN (6ES7510-1SJ01-0AB0), changes the rail, the bus adapters, and the module family around the CPU. Each difference becomes real work in the cabinet, so each one gets a line.

A mounting difference that looks minor on a datasheet becomes a wiring duct problem in practice. That is why the hardware list comes first: it decides whether the swap is an afternoon of re-termination or a rail and module family change, and both answers are legitimate outcomes of an honest comparison. Write the work estimate next to the pair, because an estimate that stays in your head cannot be challenged. The estimate is also where the two outcomes part ways: re-termination fits a maintenance window, while a rail change belongs to a project.

This is where a plausible hardware match fails quietly. A successor CPU may require a newer firmware version than the existing project or the installed engineering software supports. The unit fits, the wiring fits, and the project will not load or will not compile. Record the installed firmware and the successor's requirement as separate facts, and check both against the project version before any unit is ordered.

Enlarged system diagram

×

The gate only opens with cited data on both sides. A catalog guess does not count as a requirement.

Where the manufacturer publishes compatibility data, cite the published source in the record rather than trusting catalog similarity. Two references that sit side by side in a catalog are not a compatibility statement. A migration path that worked for one project is not evidence for the next. The citation also dates the check, which matters because compatibility data changes as products are updated.

An uncited compatibility claim is the exact failure mode this check exists to prevent. A dated citation also gives the next reviewer a place to start when the data changes, which is likely, because successor families keep moving while your installed project does not. Compatibility claims age quickly, so a claim without a date is a claim you cannot defend.

Record the engineering software version alongside the firmware versions, because compatibility runs in both directions. A successor that requires a project version you cannot install is as blocked as one whose firmware does not match, and the block surfaces at the engineering seat rather than in the cabinet. The installed software version is readable while the machine runs, so it belongs in the record before the comparison starts.

The control program is not the only binding to check. The HMI project references variables on the CPU. Connected drives and remote I/O hold relationships to it. A fail-safe application adds the safety program and its F configuration to the list. Each binding is a place where a successor that looks compatible can still break the machine.

Enlarged system diagram

×

Four binding families surround the CPU. The branches are project relationships, not network wiring.

Enumerate every project that talks to the unit and confirm, for each one, how it would be updated or migrated. The device list from the network record is the natural checklist here, because every connected device is a potential binding. Count the HMI projects separately from the drives, because they migrate through different tools. The enumeration order also suggests the restore order, because dependencies between bindings surface as you list them.

A successor accepted without these checks can stop a machine for reasons no nameplate shows. The bindings are invisible on the unit itself; they live in the projects around it, which is why the enumeration, not intuition, is the evidence. The enumeration is also what tells you how long a restore would take if the successor is accepted.

Build the binding list from the network record rather than from memory. The connected device list, the HMI project names, and the drive references are already captured in the network context if the cabinet was documented earlier, and the enumeration is then mostly bookkeeping. Where the record is missing, note the gap instead of assuming the binding does not exist. An assumed empty list is the version of this check that fails.

Close the comparison with an explicit verdict per item: matched, mismatched, or unresolved. A successor with three matched items and one unresolved item is not accepted. It is pending. The record should say which evidence would resolve the open item, so the decision cannot slide through on the strength of its strongest checks. Pending is a normal outcome, not a failure of the process.

Enlarged system diagram

×

Verdicts are per item, not per unit. One unresolved line holds the whole decision at pending.

Keep the comparison record separate from the ordering decision. The record says what was compared and what was found. The decision says who approved proceeding and when. Keeping the two apart lets a reviewer later distinguish a documented mismatch from an undocumented one, and it hands the next migration on the same machine a starting point that already exists.

Treat the outcome as conditional until the successor has been checked against the real project. Hardware, firmware, and project comparisons narrow the risk. They do not turn a successor into a proven drop-in. The honest record states what was verified on paper and what still has to be proven on the machine, and that distinction is exactly what a reviewed decision needs. What remains to be proven on the machine is exactly the list a commissioning plan should absorb.

• Compare power input, output stage, integrated I/O, mounting, and network ports as written pairs.
• Check firmware requirements against the project and engineering software versions, with cited sources.
• List every project that talks to the CPU: HMI, drives, remote I/O, and any safety program.
• One unresolved item means pending, not accepted. Say what evidence would close it.

• our PLC and CPU coverage
• the obsolete CPU planning guide
• why network context changes a replacement