Modern industrial automation systems aim for standardisation as much as possible. However, in practice, many high-performance platforms, such as PacDrive, deviate from generic IEC fault handling frameworks. There are specific reasons for why PacDrive diagnostic codes differ from standard IEC fault protocols. Why these differences exist is critical for engineers working with PacDrive motion-control systems to understand.
1. The Foundation: IEC Fault Protocols vs PacDrive Philosophy
IEC standards, such as IEC 61131-3 and IEC 61508, define broad guidelines for control programming and safety-related fault handling. These standards emphasise:
- structured programming models
- general-purpose diagnostics
- platform-independent fault categorisation
However, PacDrive was designed with a different philosophy in mind i.e the tight integration of PLC, motion control and robotics within a single platform. This necessarily requires the diagnostics to evolve beyond generic fault representation. As a result, PacDrive diagnostics are functionally richer, but less standardised reflecting the complexity of coordinated multi-axis motion systems.
2. Motion-Centric Diagnostics: A Key Differentiator
Unlike traditional PLCs which treat motion as an add-on, PacDrive treats motion as a core function. Each axis, drive and kinematic system, continuously exchange real-time data leading to:
- fault codes being tied directly to servo loop behaviour
- diagnostics linked to position, velocity and torque states
- the immediate reporting of synchronisation failures across axes
In contrast, IEC-based diagnostics often focus on high-level fault conditions instead and don’t offer the level of detail as those provided by PacDrive.
3. Multi-Layer Diagnostic Architecture
PacDrive systems operate across several layers:
- controllers
- motor drives
- field devices (encoders, IO, sensors)
Each layer generates its own diagnostic codes which are then aggregated into a hierarchy providing a deeper insight. However, this also makes direct mapping to IEC codes difficult; for example, a single machine fault may involve:
- a communication error (fieldbus level)
- a drive fault (power stage level)
- a synchronisation issue (application level)
In contrast, IEC protocols typically present such issues as separate errors, but without assigning a level of importance.
4. Real-Time Determinism and Its Impact
PacDrive operates in highly deterministic environments where cycle times can be in the sub-millisecond range. Diagnostics must therefore:
- be generated instantly
- avoid delaying control loops
- reflect transient conditions accurately
To achieve this fault codes are optimised for machine reaction speed, not necessarily for standardisation or readability. IEC protocols, by contrast, prioritise clarity and consistency over ultra-fast feedback.
5. Integration of Hardware and Application Context
PacDrive codes often merge:
- hardware-level issues e.g. encoder failure
- application state e.g. axis enabled, homed, syncing
This integration allows engineers to diagnose complex machine behaviour quickly, but diverges from IEC approaches which usually separate hardware alarms from application logic.
6. Dependency on State Machines
PacDrive controllers rely heavily on defined machine and axis state machines (e.g. Disabled, Standstill, Error Stop) and the diagnostics are often contextual, for example:
- a fault may only be raised in a specific state
- the same issue may generate different codes depending on state
IEC standards generally define faults independently of system state making PacDrive diagnostics appear inconsistent when compared directly.
7. Vendor-Specific Tooling
Interpreting PacDrive diagnostics requires tools such as:
- SoMachine Motion (formerly PacDrive Toolkit)
- Schneider Electric diagnostic interfaces
These tools provide:
- detailed fault trees
- event history logs
- axis and drive trace data
IEC-based systems, on the other hand, are designed to be compatible with many different systems.
8. Event Based Logging v Static Faults
PacDrive emphasises event sequences allowing engineers to trace:
- fault origins
- intermediate warnings
- cascading failures
This chronological approach is invaluable for troubleshooting intermittent issues, but differs from IEC’s typical snapshot-based fault reporting.
9. Customisation by Machine Builders
OEMs can extend PacDrive diagnostics within their applications. This means:
- fault codes may vary between machines
- custom alarms may coexist with system-level diagnostics
Whilst this flexibility is powerful it further distances PacDrive from standardised IEC representations.
10. Practical Implications for Engineers
For engineers familiar with IEC systems PacDrive diagnostics can initially seem:
- complex
- non-standard
- difficult to interpret without training
However, once understood, they offer:
- faster fault isolation
- better insight
- improved machine uptime
Conclusion
The differences between PacDrive diagnostic codes and standard IEC fault protocols are the result of fundamentally different design priorities. Whilst IEC standards aim for universality and consistency, PacDrive prioritises performance, motion integration and diagnostic depth.
Rather than seeing this as a limitation, it should be viewed as a specialised evolution of diagnostics tailored for high-speed, multi-axis automation systems. For businesses working with PacDrive platforms, understanding this diagnostic approach is key to minimising downtime, maximising machine uptime and maintaining machine efficiency. If engineers do not have the requisite knowledge or experience, specialist PacDrive training – including diagnostics – for both ELAU PacDrive M and PacDrive 3 is highly recommended. Breakdowns are a fact of life in manufacturing and packaging; what is critical is minimising recovery time. Understanding PacDrive diagnostic codes and how to respond to these is vital.