PLC diagnostics: record before reset

After an alarm reset, some information about the stop may no longer be visible. If conditions allow, first record the messages, time and active sequence step. Do not change settings or software just to see whether the fault disappears. For an intermittent problem, a short record captured during the stop can be more useful than watching a machine that is currently running normally.

An alarm is evidence, not a diagnosis

Several messages can follow one event. A missing device confirmation may precede a step timeout, while a drive stop generates further alarms. Start with the event order rather than the most general message on the HMI. Alarm history may contain events absent from the active list. Capture the appearance and clearance of relevant alarms where that information is available.

Check whether the PLC, HMI and devices have comparable clocks. Entries from different clocks do not necessarily establish the true order. Record the product, recipe, operating mode and latest operator action. Note recent changes to software, sensors, wiring or drive parameters. For an occasional stop, those conditions may explain more than the alarm number by itself.

Locate the stopped sequence step

Identify the active step and its completion conditions. Distinguish a start permissive from an interlock that inhibits an action, using the definitions in the actual project. You need the individual conditions and their states at the time of the fault. One combined ready bit does not identify the condition preventing the transition to the next step.

Compare the command, device confirmation and waiting time. If no command was issued, investigate the preceding logic before judging the actuator. If it was issued, investigate the response and how the program interprets it. Do not bypass interlocks or force outputs as a diagnostic shortcut. The investigation must retain required safeguards and follow the agreed working procedures for the machine.

Digital signals and analogue measurements

For a digital input, compare its description, address and program state. Separate missing physical feedback from a wrong address or inverted interpretation. For an output, establish which conditions issue the command and which withdraw it. If several parts of the program write the same signal, the final state alone may not explain why a command appeared only briefly.

For an analogue signal, the displayed number is only part of the picture. Check units, range, scaling and channel status. A value near an alarm threshold may fluctuate in a way that a single panel reading misses. Use a trend to compare the measurement with the stop. Do not move the threshold to silence an alarm before determining whether the process, measurement or conversion changed.

Communication and stale values

A connected status does not fully describe device operation. Check controller, module and partner diagnostics, along with the freshness of values used by the sequence. A retained last value can look plausible while no longer representing the current cycle. Establish how the program detects a missing response and what happens when the connection returns.

For brief faults, log selected communication states with sequence steps and feedback. Choose a sampling interval suited to the event and document the timestamp source. An online observation minutes later may show an already recovered connection. Absence of an error at that point does not prove communication was unrelated to the stop. Keep recorded observations distinct from hypotheses.

Resetting and making changes

Reset according to the machine procedure after assessing its state. Repeated resets without recording evidence can erase the pattern of a recurring fault. Running again confirms that operation resumed, not that the cause was removed. Increasing a timeout without investigation can also hide a device problem or a missing process condition.

Save the current project before a correction and agree a test covering the original fault conditions and other affected functions. Define service and diagnostics from the evidence collected. Where a logic problem is confirmed, PLC modifications become a separate, specified action rather than a sequence of speculative downloads.

Information for a service request

A useful request contains:

• an alarm image and the relevant event history
• PLC and HMI types and available project backups
• the sequence step, product and circumstances of the stop
• recent changes and actions taken after the fault
• site access arrangements and permission for remote reading.

This helps identify the next check and the support needed on site. If an item is unknown, say so rather than presenting an unconfirmed cause as a conclusion.