An intermittent PacDrive fault can leave an engineer investigating a machine that currently appears healthy.
Production reports it stopped earlier. Someone reset it and the line is running again. You have a description of the alarm, perhaps a photograph and a request to make sure it does not happen again.
However, the difficulty is establishing what happened whilst the fault was present.
Machine Analyser® helps make retained PacDrive diagnostic information available for investigation. Its value is in how this information is used: to understand the sequence of events, help narrow down the possible causes and provide direction for the next engineering check.
Ultimately, the data provides evidence to help engineers build a diagnosis.
Start with the reported symptom
Before opening a diagnostic history it must be established what production actually experienced.
Did the machine stop completely? Did one mechanism fail to move? Was any product damaged? Did the issue occur during start-up, a changeover or normal production?
The message displayed should be recorded where available including the approximate time and what happened immediately afterwards.
A reset, power cycle or parameter adjustment can change the state being investigated. Knowing which actions were taken helps interpret the remaining evidence.
It should also be established whether the event was isolated or recurring. A fault happening every morning may require a different investigation from one which appears after several hours at full production speed.
All these details give the diagnostic history a useful frame of reference.
Understand the affected machine function
A component reference identifies equipment, but it does not explain its function.
If the diagnostic points towards a motor, the next step is to establish what that motor drives and how the mechanism normally behaves.
A conveyor running steadily, a sealing mechanism working against a load and a pick-and-place unit repeatedly accelerating and reversing all have different operating demands.
This context matters when interpreting messages involving loading, movement or feedback.
It should also be identifed when the mechanism is under greatest demand. For example, has the product, speed or movement profile changed? Does the fault correspond with a particular position or part of the cycle?
Understanding what normal operation look like will help identify which recorded events deserve closer attention.
Review the captured sequence
Machine Analyser®’s 500-message pre-fault event log provides a sequence for review rather than leaving the investigation dependent on a single displayed alarm.
Start by looking around the reported time and identifying any relevant messages, affected devices and order of events. Look for recurring messages before the stop, associated faults and patterns which appear across previous incidents.
However, sequence alone does not establish cause. The earliest recorded message may be significant, but it may also reflect a separate condition. Several messages may be consequences of the same interruption.
Then check whether the timing is consistent with the operator’s account and whether the selected history covers the event being investigated.
In this respect a useful question to ask is, what does this sequence help us test?
Narrow down the possible causes
Suppose the evidence includes a loading-related diagnostic associated with a particular motor.
Such a finding may direct attention towards the operating demand and the equipment involved: however, it does not automatically meant the motor or drive is faulty.
Mechanical resistance, changing product conditions, movement demands or an electrical problem may require investigation. Similarly, movement-related diagnostics need to be considered alongside the machine function and associated events.
A useful investigation should convert all available evidence into a short list of possible causes.
For each possibility, then ask what observation or test would support it and what would make it less likely.
This helps prevent a diagnostic history from becoming another long list of information without a clear next action.
Check the machine against the evidence
The next step is physical and technical verification.
Depending on the fault, this may involve inspection, appropriate measurements, checking connections, reviewing configuration or observing operation under controlled conditions.
The relevant safety procedures should be followed and the existing configuration saved before making authorised changes. Where practical only one variable should be changed at a time.
If several components are replaced and parameters adjusted together, a successful restart may leave the original cause unresolved. This will likely cause problems should the fault return later.
Record what was checked, what was found and why the next action was chosen, distinguishing clearly between a suspected cause and a confirmed finding.
Verify the result
After corrective action, check the machine under conditions relevant to the original fault.
A mechanism which moves slowly during a test may behave differently under full operation. This could mean an intermittent issue may need a longer observation period before any result can be assessed.
Next review whether the original diagnostic pattern returns and record the operating conditions and any limitations on the checks performed.
Remember a restart is an outcome: establishing that the corrective action addressed the cause requires further evidence. Such a distinction protects the integrity of the investigation and also gives other engineers a reliable record.
Make the investigation reusable
The final record should connect the symptom, diagnostic sequence, checks, findings, corrective action and verification.
Machine Analyser® supports this process by making diagnostic history available for review. Engineering knowledge turns that history into decisions.
For engineering, maintenance and reliability teams the benefit is a more traceable investigation and a robust platform for addressing recurring faults.