The evidence has usually disappeared before the diagnosis starts
The most useful diagnostic evidence on a PacDrive line has normally gone by the time an engineer begins to look for it.
For example, a machine faults mid-shift. However, production needs output so someone acknowledges the alarm, resets the controller or power-cycles the panel and the line runs again. Then three hours later an engineer connects a laptop and finds a machine reporting no issues. Even on a healthy PacDrive 3 LMC controller a busy log will overwrite its oldest entries while the shift carries on.
So the question to ask is not necessarily …”what fault stopped the line?” Instead it is …“what was this machine reporting in the minutes before it stopped and can I still see it?”
A fault code is one moment in a sequence
PacDrive diagnostics were built around sequences rather than snapshots. We covered the reasons in Why ELAU PacDrive PDM Diagnostic Codes Differ From Standard IEC Fault Protocols. IEC-style fault handling tends to report the condition which exists now. PacDrive logs a chain of events across controller, drive and axis levels as the machine changes state.
This distinction matters during a breakdown as the final error is frequently a consequence rather than a cause. One axis trips, the controller commands an error stop and every other axis on the line reports a synchronisation fault a fraction of a second later. However, the operator only observes the last event as this is when the alarm sounds: the first event goes unnoticed.
So, if the last code is read in isolation there is a significant risk of only diagnosing the symptom.
The 500-message pre-fault event log
The message logger in a way acts as the machine’s black box. As soon as the machine goes into error it begins to take diagnostics, keeping up to 500 messages via the message logger. However, once this threshold is exceeded the first message is expelled to make room for new ones. But all is not lost as Machine Analyser® still retains all data from when it was first connected. This means that should there be insufficient information in the 500 messages which precede the stop, it is still possible to go back further to establish what errors there were which have been cleared in the meantime.
It must be remembered that error messages don’t themselves specificy what action may need to be taken. Still, with both a diagnostic file and Machine Analyser® there are suggested steps to take for a given fault code depending on what caused the error. Ultimately, what is offered is a record of the sequence of events leading to failure. So whilst Machine Analyser® via its limitless message logger prevents evidence being lost, an engineer is still required. Importantly though, they will have data on which to base their investigations.
From event history to root-cause investigation
Below is a sequence of events a Lexium 62 axis might produce on a PacDrive 3 machine (all the events and timings below are illustrative only).
| # | Time | Event | Level |
| 1 | 14:22:06.1 | Communication event on axis 4, self-clears | Drive |
| 2 | 14:22:08.4 | Axis 4 drive loading above its normal band | Drive |
| 3 | 14:22:11.7 | Following error warning, axis 4 | Axis |
| 4 | 14:22:12.0 | Following error limit exceeded, axis 4 | Axis |
| 5 | 14:22:12.0 | Controller commands error stop | Controller |
| 6 | 14:22:12.1 | Axes 1, 2, 3, 5 report synchronisation loss | Axis |
The alarm on the HMI is signalled at event 6. However, the investigation begins at event 1.
This provides a logical sequence to follow for any stop:
- Sequence: find the first event which means something, not the one which raised the alarm.
- Scope: establish which device or axis was first affected and which followed it.
- Test: use the timing and the machine function at that moment to decide what should be physically checked.
If both the sequence and the scope are established then the testing options narrow as a consequence.
Intermittent faults are where history proves its worth
Intermittent faults can be very difficult for engineers to resolve if there are no records. For example, the machine drops out once a shift, once a day or even once a fortnight, clears itself and runs with no issues whenever anyone is present. This means when the engineer arrives they end up inspecting what is evidently a healthy machine.
Retained history changes what you have to work with. A following error which appears twice a shift and clears is a pattern. A communication event which shows up before every stop is a pattern. However, neither is visible if the evidence resets with the machine. Both though, would provide something specific to investigate rather than a fault you have to wait for and hope to catch.
What this changes during a breakdown
The traditional process is all too familiar. Arrive, connect a laptop, try to reproduce the problem, search whatever logs remain and then begin diagnosis. Reproducing an intermittent fault on demand is can be very difficult – if even possible – as well as being extremely time consuming.
With the history retained the starting point is different. The event record is opened in a browser, the sequence established and narrowed down to the affected device or axis which can then be inspected or tested. How much time this saves depends on the fault, the machine and the engineer. But what it does remove is the need to try and recreate an event or events the machine has already been through.
Data supports the engineer, but does not replace them
Machine Analyser® preserves and presents data the PacDrive system was reporting. Although it will suggest steps to take, it won’t tell you whether the root cause is a worn mechanical component, a faulty cable or a failing MC-4 drive. This resides with the engineer and still requires knowledge of the machine and process.
Conclusion
The value of a diagnostic system is not only that it shows the fault which stopped the machine. It is that it preserves the evidence explaining how the machine reached that point.
Try asking what your line would still be able to tell you three hours after a reset. If the answer is “one alarm code and whatever the operator remembers,” then this is a gap worth closing.