What evidence to send with a PLC request

A useful PLC request is a pack, not a sentence. It pairs the exact reference with photos, dated symptoms, backup status, and a stated route, so a reviewer can start the real work on the first pass. Four groups of evidence do the work: identity, context and symptoms, network summary, and the route itself. Each group removes one round of questions. The pattern repeats because requests are read rather than interviewed, so anything you leave out is read as absent, and the review starts from that absence.

Enlarged system diagram

×

Each group fills a different gap in the review. A request missing one group needs an extra round trip before work can start.

The order matters because the reviewer reads in a sequence: who is asking about which unit, in what machine, with what state, and toward which recovery route. A request that leads with urgency and ends with a partial reference gets read backwards, and the review restarts once the real evidence arrives. Each answer needs its own field, because a reviewer who has to email you for one field waits on the others.

This section walks through each group in the order the request should carry it. The aim is not paperwork for its own sake. It is a request the reviewer can act on without asking you to send anything twice.

It helps to know what a missing group costs. A request without identity evidence gets a generic reply and a request for the nameplate. A request without symptom dates gets a reply that treats the fault as recollection. A request without a route gets a reply that covers all routes shallowly. None of those replies is wrong; each one is simply the review of the evidence you actually sent, which is why the pack, not the email, is the deliverable.

Start with the full order number and revision, for example a Siemens 6ES7214-1AG40-0XB0 with its version marking, plus a clear nameplate photo. Shortened references invite wrong matches, because 6ES7214 alone names every CPU 1214C variant ever produced and cannot separate a DC/DC/DC unit from its relay-output sibling. The photo backs the typed string, and the two should agree. A photo also settles case and spacing questions that a typed string cannot settle on its own.

Enlarged system diagram

×

The photo and the typed string check each other. Source tags then tell the reviewer how much weight each value carries.

Add the family line and the firmware state if known, and mark each value with its source: nameplate, engineering tool, or parts list. A firmware value read from the engineering tool carries different weight than one recalled from memory, and the reviewer needs to know which is which. Where a value is unknown, write unknown rather than leaving the field blank. An explicit gap is easier to plan around than a silent one.

A typed string that disagrees with its photo is a red flag the reviewer will chase first, so resolve the disagreement before sending if you can. The reviewer reads the source tag before the value itself, because the source decides how much weight the value carries in the review. Settling it yourself costs minutes; settling it in the review costs a cycle.

If the CPU sits in a fail-safe application, say so in the first lines of the request. The F status changes which questions the reviewer asks next and which recovery routes are even discussable. It is not a detail to bury in an attachment.

Enlarged system diagram

×

Both branches reach the same intake, but the undeclared one pays for a wasted round first.

A request that hides the safety role costs a full round of questions before any real review can start, because the reviewer builds an intake path that has to be rebuilt once the F marking appears. The cost is not only time. Safety-related review involves different people, and they need to be pulled in early.

Say it plainly and let the reviewer decide what follows. You do not need to prove the F role in the request; a nameplate photo showing the F marking, or a note that the machine documentation names the safety function, is enough to open the right path. The reviewer's first question is which evidence supports the claim, so name it yourself.

In practice, first lines means what the reviewer reads first: the subject line and the opening sentence of the description. Writing fail-safe CPU, order number pending in the subject line costs nothing and routes the request correctly before anyone opens an attachment. Burying the F status in the fourth paragraph of an attachment does the opposite. Put the facts that change the intake path where the intake path starts.

Describe the machine, what stopped, and the dated symptom history: which LEDs were active, which error codes appeared, and whether the fault repeats after a controlled restart. Note what has already been tried and what changed, because prior interventions steer both a repair assessment and a replacement check. Symptoms without dates force the reviewer to treat everything as recollection. Dates turn a symptom into a pattern.

Enlarged system diagram

×

Three context inputs shape the plan. A missing one does not stop the review, but it turns a stated fact into an open question.

State whether a verified project backup exists and where it is stored. This single fact changes the shape of every route. A replacement with a verified backup is a restoration task. The same replacement without one includes a program rebuild. If the backup has not been opened and checked against the running program, say the backup is unverified rather than assuming it works. The storage location belongs in the request, because a backup nobody can reach behaves like a missing one.

Include the network context summary: device name, addressing if known, and the connected device list with drives, HMIs, and remote I/O. This turns a reference question into a restorable plan, because the reviewer can see what the replacement would have to re-establish and in which order. A rack overview photo plus the port photos from the cabinet cover most of what this group needs.

State the route you prefer, such as sourcing, repair, exchange, or replacement, and the downtime tolerance with the decision owner. A preference is not a commitment, but it directs the review toward the evidence that route needs, away from a generic inquiry. Downtime tolerance matters for the same reason. Urgency is a fact about the business, and the review can only weigh it if it is stated.

Enlarged system diagram

×

The close has three parts: the route, the attachments, and the copy you keep. Each one prevents a later round trip.

Attach the files rather than describing them: nameplate photos, the rack overview, symptom notes, and any project backup record. A request that says photos available on request adds a round trip before anything can be reviewed. Attachments also keep the wording of labels exactly as printed, which paraphrase loses. Name the files by content so the reviewer can cite them back to you without reopening the whole set.

Submit the pack through the request form and keep your own copy of everything sent. The same evidence supports the next step, whichever route the review confirms. Your copy is what makes the record reusable when the machine fails again or a sister line shows the same fault. A request built this way leaves behind an evidence pack the site still owns, so next time the pack already exists.

The kept copy earns its place later. When a sister line shows the same fault, the pack answers the identification questions in minutes. When the machine fails again after a route was rejected, the pack shows what was already tried and which evidence closed the earlier review. And when a successor check starts, the network summary and backup status are already written. One submission, reused several times, is the quiet return on the effort.

• Send the full order number, revision, and a clear nameplate photo, with a source for each value.
• State backup status, fail-safe involvement, and dated symptoms. Write unknown where a value is unknown.
• Include the network summary: device name, addressing, and the connected device list.
• State your route and downtime tolerance, attach the files, and keep your own copy.

• the PLC CPU category
• send the evidence pack through the request form
• what to photograph in the cabinet
• the repair or replace evidence guide