PLC CPU or I/O module: what is the difference?

A machine stops and the question lands on you: which unit in this rack failed? A PLC CPU executes the control program cycle, manages the network connection, and coordinates every module mounted around it. An I/O module does none of that. A digital input card reports field signals, such as sensor on and off states, to the CPU. An analog output card hands setpoints, like a speed reference, back to the field.

Enlarged system diagram

×

The arrows show the division of work, not wiring. The CPU is the only unit that decides; the modules carry signals in and out.

The distinction sounds basic until someone has to decide which unit actually failed, because both sit side by side on the same rail and can look alike. The CPU is the only unit that runs the program; every other unit either reports field signals to it or acts on commands from it. That division of work is the anchor for everything that follows.

The distinction also changes what a request should contain. A dead input card is a low-stakes sourcing question with the cabinet still running on its remaining channels. A failed CPU puts the program, the network identity, and the machine tuning at stake. That is a different evidence problem, even though both units sit in the same rack. A low-stakes request still needs the full reference, because a wrong input card arrives just as confidently as a wrong CPU.

It helps to know what the program cycle is, because the whole division of work hangs on it. The CPU repeats the same loop continuously: read the inputs, execute the program, write the outputs. The loop runs many times per second, and every I/O module only participates in it as a source of readings or a target of commands. Nothing on the module side decides anything; decisions happen in the CPU or nowhere.

Failure behavior separates the roles in practice. A failed CPU usually takes the whole program and the communications down with it, so the machine stops as a unit and the HMI, the operator screen, loses its connection. A failed I/O channel often shows up as a single diagnostic, so one actuator drops out while the rest of the machine keeps running in a degraded state.

Enlarged system diagram

×

Two behavior patterns, two suspect lists. Recording the pattern with a date keeps the classification checkable later.

Record which behavior you saw, with a time and date. Both patterns fit in one sentence each, and both are stronger evidence than a memory of the event. Even a rough timestamp narrows what a reviewer later checks. The behavior is the fastest classification clue you will ever get, and it costs nothing because you already watched it happen.

Neither pattern is proof on its own. A communications fault can look like a CPU failure from the outside, and a wiring problem can mimic a dead input channel. The recorded behavior narrows the list; it does not close it. That is why the behavior goes into the record next to the classification, not instead of it.

Treat a degraded running state with the same care as a full stop. A machine that keeps running with one channel out is still telling you which unit failed, but it is also still producing parts, so the pressure is to defer the record until the shift ends. Write the one-line observation anyway, because the degraded state is exactly the evidence a reviewer needs and exactly the detail that blurs by the end of a shift.

Family naming gives the first structural clue. The Siemens order number 6ES7214-1AG40-0XB0 opens with 6ES7, and the 214 block selects the CPU 1214C. Signal modules inside the same S7-1200 family carry a different digit block in that position. Read the second block of the order number and you classify an unknown module faster than any guess about its size or color.

Enlarged system diagram

×

One block sorts the rack. The photo turns the classification into evidence a reviewer can check.

That block does not move, no matter which catalog you read, which makes it more reliable than appearance. Photograph the nameplate of every module you classify, including modules you do not suspect, because a classification you cannot show later is only a memory. The photo also feeds the line-item record the request will need. Note the slot position next to the reading, because the position is half of what identifies the unit.

Slot position is evidence as well, because the same reference can appear twice in one rack and the project may address each occurrence differently. A rack overview photo plus one label photo per module makes the whole set reconstructable later, without a second cabinet visit. The block reading, the slot, and the photo line up on the same unit, which is what makes the classification checkable.

Physical layout adds confirmation. The CPU carries the PROFINET port, the Ethernet connection the control network runs on, and on a CPU 1214C it also carries a small status display. Signal modules present rows of terminals for field wiring and no network interface of their own. A port is a strong clue because almost no I/O module has one.

Enlarged system diagram

×

The port and the cable destination work together. The arrows describe an observation method, not a network diagram.

The reverse case matters too: on a distributed I/O station built around a CPU 1510SP-1 PN (6ES7510-1SJ01-0AB0), the ET 200SP modules around the CPU look alike and share the same rail. There, the network port and the order number blocks are the reliable separators, not appearance. One glance settles what a part number never could. Photograph the port and the cable in the same frame where possible, so the destination is visible without a second photo.

If you cannot tell which unit controls the rack, follow the network cable. The module whose port connects to the engineering laptop, the network switch, or the HMI is almost always the CPU, because I/O modules have no independent network presence. Note that observation in the record along with the cable destination. It is evidence even before any nameplate is read.

The small status display on some CPUs is a third clue. It typically shows a status word or a brief diagnostic, and a photo of it at the moment of failure is evidence of the CPU's own state, not of the field side. Absence matters too: a unit with terminals and no display and no port is almost certainly an I/O module regardless of what its label suggests, and that observation costs nothing to record next to the photo.

List the CPU and each I/O module as separate line items with their own full order numbers. A request that mixes them into one description forces the reviewer to guess which unit is the controller. One wrong guess wastes a sourcing cycle. Line items with slot positions remove the guesswork, and the slot number comes straight from your rack overview photo, so the two records reinforce each other.

Enlarged system diagram

×

Three inputs make the request reviewable: the line items, the per-line evidence, and the dated behavior. None of them needs a second cabinet visit.

State the failure behavior you observed next to the module you suspect. Which channels dropped, whether the HMI stayed connected, whether the fault repeats: one line on each gives the reviewer something to test the classification against. That context costs one line to record and separates a useful request from a parts list. A line item that cannot be traced back to a photo is a claim, and claims are what this record exists to avoid.

The finished list protects the request if the classification is questioned later. Each line carries its own evidence: the block reading, the port observation, the photo, and the behavior. A reviewer can then confirm or correct one line without reopening the whole rack, which is what keeps a stoppage short.

• The second block of the order number classifies the module; 214 marks a CPU 1214C.
• Follow the network cable to find the controller. I/O modules have no port of their own.
• List CPU and I/O references as separate line items with slot positions.
• Note the failure behavior: a whole-machine stop and a single channel fault point at different units.

• PLC and CPU reference hub
• how to read the nameplate fields
• the fail-safe recovery evidence list