PLC repair or replacement: which evidence helps?

The machine is down, someone is asking for a quote, and the temptation is to describe the fault from memory. Resist it. Write down what the machine did before it stopped: which LEDs were active on the CPU, which error codes appeared, and whether the fault repeats after a controlled restart. A symptom without a date and a source is a story, and a repair assessment built on stories produces quotes for the wrong fault.

Enlarged system diagram

×

Three observations make a symptom usable. The date is what lets two incidents be compared at all.

Note what has already been tried and what changed as a result. A power cycle that cleared the fault for two hours, a replaced sensor that had no effect, a cable reseated before the stop: these are facts that steer a diagnosis. Without that history, a repair shop repeats the same steps and bills for the privilege, while a replacement decision gets made on incomplete information.

Photographs of the LED states at the moment of failure count as observation and survive better than descriptions. A timestamp on the note is what makes it comparable later, because two incidents described identically can be different faults once the dates and conditions are compared. A photo taken during the first minute of the stoppage outlives every recollection of it.

One caution belongs with the symptom gathering. Observations that come from operating the machine, such as watching which LEDs are active at the moment of failure, are safe to record. Interventions that change the machine's state, such as restarting or reseating, belong to the site's own procedure and its safe condition. Record what was done and when, and leave the doing to the people and the process responsible for it.

Keep the symptom record factual and free of conclusions. A note that reads power LED off, SF active, occurred twice this week after line start is usable evidence. A note that reads the CPU is probably dead is a conclusion, and it can close off a cheaper route before anyone has looked at the unit.

Enlarged system diagram

×

Two kinds of content reach the record. Only the observed part carries weight until someone verifies it.

The discipline is the same one that keeps any evidence honest: separate what you saw from what you think it means. The observation belongs in the record. The interpretation belongs in a clearly marked note, if it belongs anywhere, because a reviewer needs to know which part they are being asked to verify.

The same separation decides how the record is used later. A factual record can be handed to a repair assessor, quoted in a replacement review, and reused for the next fault. A record of conclusions can only be argued with. Keep it factual, and the record does work for years.

A CPU carries the program, the network identity, and the machine tuning, and the recovery work differs completely depending on whether that content is backed up. If a verified project backup exists, a replacement becomes a restoration task: load the project, restore the device name and addressing, and verify the connected devices. If no backup exists, a replacement means rebuilding the program from documentation or from the failed unit.

Enlarged system diagram

×

One fact, verified backup or not, changes the cost of the whole route. Arrows show the two cost paths.

Those are different projects in scale and cost, and the gap is measured in weeks of engineering time, not in the price of the unit. The unit price is rarely where the real cost lives. A quote that looks expensive next to a cheap replacement can be the cheaper route once the rebuild is counted, and only the recorded backup status exposes that. A backup that opens is a fact; a backup that is assumed to open is the risk the record exists to retire.

Verify the backup rather than trusting its existence. A file that opens in the engineering software and matches the running CPU's program version is a verified backup. A file of unknown age on a shared drive is not. The verification step is quick while the machine runs, and it decides which route is realistic long before anyone requests a quote.

Machine tuning is the quiet part of the backup question. Beyond the program, a CPU may carry parameters that were adjusted during commissioning and never written down anywhere else. If the backup status is unknown, the tuning question is unknown with it, and that uncertainty belongs in the record next to the backup status. It changes the value of a recovered unit as much as the program does.

For a repair lead, gather the full reference with revision, the dated fault history, and clear photos of the unit including its label. Repair assessment lives on symptoms and unit condition, so that set is the core. Add whether the unit was opened or modified, because unrecorded interventions change what a repair shop can conclude from inspection. Details that feel minor at the bench often decide the assessment.

Enlarged system diagram

×

Both routes start from the same record and branch into the evidence each assessment actually weighs.

For a replacement, add the network and project context so a successor or matching unit can be checked properly. The relevant set includes the device name, the addressing, the connected device list, and the verified backup status. The replacement route is decided by configuration evidence more than by fault evidence. A matching unit without its network context is still a guess.

That is why the two routes pull on different parts of the same record. Build both evidence sets from one factual symptom record and one verified backup status, and each route gets what it needs without the work being done twice. Saying which interventions were recorded, and which were not, is itself useful evidence for the assessor.

Unrecorded interventions deserve a line of their own in both evidence sets. A unit that was opened, a module that was swapped between racks, a terminal that was re-terminated during an earlier fault: each of these changes what an assessor can conclude and what a replacement check should verify. Recording them is not an admission of fault; it is the difference between an inspection that starts from facts and one that starts from surprises.

Downtime tolerance belongs in the pack as well. State how long the machine can wait, whether a temporary workaround exists, and who owns the decision. Urgency is a fact about the business, and recording it lets the evidence, not the pressure of the moment, drive which route gets confirmed with the people responsible for the machine.

Enlarged system diagram

×

Three inputs, one comparison. The tolerance and owner keep urgency inside the record instead of inside the decision.

An exchange offer and a repair quote answer different questions. The exchange answers how fast a machine runs again; the repair answers what happened to the unit and what a restored one is worth. The pack keeps the two from being compared on price alone, because price alone is what a pressured decision falls back on.

The record makes that comparison possible months later. A decision made under downtime pressure, with the tolerance stated and the evidence attached, can be reviewed and learned from. A decision made without the record can only be regretted or repeated. The comparison, not the choice, is what the evidence is for.

A temporary workaround changes the arithmetic and should be recorded as a fact. If the line can run on a sister machine, or in a reduced mode, the downtime tolerance is a different number than for a hard stop, and the routes can be weighed against the real deadline. State the workaround, its limits, and how long it can hold. Workarounds that are assumed to hold indefinitely are where plans quietly fail.

• Record dated, specific symptoms and every prior intervention before requesting anything.
• Verify the project backup opens and matches the running program version.
• Build repair evidence from symptoms and photos, replacement evidence from network and project context.
• State the downtime tolerance so the comparison is honest about urgency.

• the PLC CPU category page
• what to record before fail-safe recovery
• what to send with a repair request