What evidence to send with an HMI request

Everything a reviewer does starts from one string: the order number printed on the panel, with its revision. The chain is simple. The rear label carries the string, a focused photo proves it, and the proven string becomes the canonical reference for the whole request. When the label is worn, the panel diagnostics page takes over the same role. One trusted identity, everything else attached to it.

Enlarged system diagram

×

Read left to right: the printed reference is proven by a photo and recorded once as canonical. Photos support identity, they do not diagnose the fault.

Why is shortened shorthand such a problem. Family names such as KTP700 or PanelView Plus 7 cover multiple order numbers that differ in ports, power options, and hardware generation. A full string such as 6AV2124-0XC02-0AX1 names one exact unit, while two listings can both claim KTP700 and ship different products. The order number fixes all of that, which is why it leads the pack.

Keep the string in one piece, including 2711P-T10C22D8S style trailing blocks. The trailing part is the segment most often lost when a reference gets retyped or read over the phone, and it is exactly the segment that separates hardware revisions. If the rear label is unreadable, photograph the diagnostics page instead, since most HMIs print their exact order number and firmware version on screen.

A limit matters here. The order number identifies the unit, nothing more. It does not confirm the fault, the compatibility of a replacement, or the price. Those need the rest of the pack, which is what the following sections collect.

Three photos do most of the identity work in this pack, and each one answers a different question. The rear label photo proves the reference. The bezel photo places the panel in its family and size. The powered screen photo documents the fault state, or confirms the runtime was healthy before removal. Together they let a reviewer work without visiting the machine.

Enlarged system diagram

×

Each branch answers one identity question and all three meet at the review. None of them proves a component failure on its own.

The rear label deserves the most care. Shoot it straight on, in focus, and zoomed enough that revision and suffix fields stay readable. A blurred suffix can hide the difference between two hardware generations of the same model. If the label is damaged, open the panel diagnostics or info page and photograph that instead, because the on-screen order number works just as well.

The powered screen photo earns its place twice. It captures the symptom if one exists, and it shows whether the panel reached its runtime instead of failing at power on. A reviewer reads that difference immediately. One extra photo, two answers.

Photos prove state, not cause. A screen that shows a frozen page on Monday may behave differently on Friday, so date every image and keep the originals. A compressed screenshot that blurs the label suffix is the most common way this evidence loses its value.

Symptoms belong in the pack as three separate records, not one sentence. Touch, image, and power behavior can fail independently, and the reviewer treats them as different fault classes. Write one line per layer, with the date each behavior was first noticed. A dated history also separates a sudden fault after an event, such as a power outage, from a gradual one like a fading backlight.

Enlarged system diagram

×

The three layers are recorded separately and meet at the test summary. Arrows show information flow, not any electrical path.

Include the isolation tests you already ran, with results. A USB mouse that moves the cursor while the touch layer does not respond points away from the project and toward the touch input path. A flashlight held against a dark screen that reveals faint content points to the backlight rather than the whole display. Mark every conclusion as provisional, because these tests narrow the field without identifying a failed part.

This is a two minute job at the panel, and it shortens the review by days. A record that says image failed slowly over three weeks while touch stayed accurate reads very differently from a record that says the panel is broken. Same panel, opposite directions for the investigation.

Keep symptoms and interpretations apart in the text. Write what you saw, then what you think it means, then what you are unsure about. A reviewer can challenge an interpretation. A mixed sentence that fuses observation and theory cannot be checked at all.

Two facts decide which routes are even possible, so they sit next in the pack. The first is project status: whether a verified project backup exists, and which tool built the project. A TIA Portal project, a FactoryTalk View .apa archive, and an EasyBuilder project file each imply different transfer and compatibility checks. Naming the tool and version up front removes one round of questions.

Enlarged system diagram

×

Both inputs narrow the review before any price is discussed. They set scope, they do not confirm availability.

The second fact is the port list with the controller protocol. Whether the panel reaches its PLC over PROFINET, EtherNet/IP, or a serial link decides which replacement candidates can serve the machine at all. Attach accessories and option modules to this list, since they are sometimes the scarce part rather than the panel.

These two facts work together, which is why they share a section. A verified backup plus a common port set makes an exchange realistic. No backup plus a legacy serial link pushes the review toward preserving the panel storage. Same machine, different routes, decided by two lines of text.

If either fact is unknown, write unknown and say what you checked. A request that admits the project file cannot be found is more useful than one that stays silent, because the reviewer plans for a rebuild instead of discovering the gap mid review.

The installation block is short but it prevents a second site visit. Cutout dimensions or a door photo, the front ingress rating, and the worst temperature or cleaning conditions let a reviewer judge physical fit from the desk. Keep it to five lines. The linked environment guide explains what each line is for, and the reviewer only needs what changes the fit.

Enlarged system diagram

×

Three context streams meet in the pack. They inform the review, they do not by themselves prove a cause.

Past attempts belong here too, listed with dates. A power cycle that cleared the fault, a spare that failed the same way, or a cable swap that changed the symptom all shorten the review. A repeated failed fix changes its direction entirely, because the next reviewer stops proposing it.

Prior repair history counts as context as well. If the panel was opened before, say by whom and what was replaced, since a bench prices the work differently when non original parts sit inside the housing. If the unit came from a shelf spare, record how long it was stored and where.

One limit applies to all of this. Context helps the reviewer interpret, it does not prove anything about the current fault. A panel that failed the day after a cabinet cleaning may or may not be related to the cleaning, and both facts should stay visible rather than fused into a cause.

Close with the operating stakes and your preferred route. Say which line or function is down, how long the downtime tolerance is, and how many identical panels the plant runs. Then state the preferred route, such as repair, exchange, exact reference sourcing, or replacement, with the constraint behind it, for example no project backup or a fixed cutout.

Enlarged system diagram

×

Read left to right as the closing sequence of the pack. The review outcome stays open until the provider checks it.

A preference with a reason is reviewable, so write the reason down. An unexplained preference usually gets relitigated later, which is exactly the back and forth this pack exists to avoid. The constraint also protects you, because it stops a technically valid answer that cannot actually serve the machine.

Submit the pack through the request form with all files attached, and keep your own copy. The same pack serves whichever route the review confirms, and dated photos protect you if the panel state changes between request and shipment. Name a contact who can answer follow up questions about the machine. A review that stalls on one missing detail loses days.

Keep the pack consistent across channels. If the same request also goes to a supplier or a repair shop, send the same evidence rather than a shortened version, so the answers stay comparable. And keep the commercial questions open in the text: availability, price, repair success, and migration effort depend on checks the provider performs, and a complete evidence pack is what makes those checks fast.

• Send the full printed order number with the rear label photo that proves it.
• Record symptoms by layer with dates and test results, conclusions provisional.
• Put backup status, port list, and installation constraints in the same pack.
• Close with downtime tolerance, installed base, and a preferred route with its constraint.

• the category overview for HMI panels
• send the HMI evidence pack through the request form
• the repair or exchange evidence guide
• recording model variants and revisions