Before the PLC service call
What to Send Before a PLC Service Call
The best starting point is not a theory about the failed part. It is a clear record of what the machine should do, what it does now and what changed before the fault appeared.
Useful fault context
Preserve the chain around the stop.
A technician can usually start faster when the symptom, alarm, machine sequence and recent operating context stay connected instead of arriving as separate pieces of information.
Field checklist
Five things worth capturing before the visit.
Use the list as preparation, not as a requirement to delay the call. If the machine is down now, start the request and attach the information you already have.
Identify the equipment
Give enough context to distinguish the machine and control system from every other asset on site.
- Machine or line name and asset number
- Manufacturer and model
- PLC, HMI and VFD model numbers
- Site location and best maintenance contact
Describe the actual symptom
Start with operating behaviour, not a guessed failed component. The sequence around the fault is often more useful than the theory.
- What should happen next
- What happens instead
- Exact alarm or fault text
- Whether the problem is repeatable or intermittent
Record timing and conditions
Patterns can narrow the fault path before the cabinet is opened or the software is connected.
- When the issue began
- Product, speed or load at the time
- Warm-up, temperature or shift pattern
- How the system is currently being reset
Collect available files
Backups and drawings reduce uncertainty, but missing files should not delay the first conversation.
- PLC and HMI backups
- Electrical schematics and I/O lists
- VFD parameter files
- Photos or a short video of the fault sequence
Important
Do not send passwords through an unsecured channel. Confirm a secure transfer method when credentials are required.
Protect the current state
Avoid creating a second problem while trying to prepare for the service call. Preserve useful history and record changes already made.
- Record parameters or logic already changed
- Do not clear useful fault history without noting it
- Identify current production constraints
- Confirm who can authorize a software or parameter change
High-value evidence
If you only send four things, start here.
These items are quick to capture and often reveal the platform, fault timing and machine state without requiring the customer to diagnose the control system.
Alarm screen
A clear photo is usually better than retyping the message from memory.
Cabinet overview
One wide photo plus close-ups of PLC/HMI/VFD labels helps identify the platform.
Short fault video
Capture the sequence before, during and immediately after the stop when safe to do so.
Recent changes
Mention maintenance, parameter changes, replaced devices, power events or product changes.
Before changing anything else
Preserve evidence first.
Do not clear alarms, change several parameters or overwrite a known backup just to make the request look complete. Record what has already been tried and keep the current state available for troubleshooting.
Keep Alarm history and timestampsRecord Parameter or logic changes already madeConfirm Who can authorize an online changeShare securely Credentials only through an agreed method
Machine down now?
Send the symptom first. Add the files as they become available.
Equipment identity, exact alarm text and a short description of the sequence are enough to start the technical conversation.