Why CAN alone is insufficient, and a complete CANopen architecture is mandatory for motion control?

Automation and Control Industrial Automation and Control
1

Only the coordination of the complete three-layer CANopen architecture can realize standardized motor motion control.

Why Pure CAN Cannot Support Motion Control, While a Full CANopen Stack Can?

Pure CAN only provides low-level drivers without standardized communication objects

Pure CAN does not define core concepts including PDO, SDO, SYNC and NMT. Users have to customize message IDs, data formats and synchronization mechanisms from scratch, resulting in incompatibility between motors of different brands. The complete standardized module of the intermediate communication layer shown in the figure is exclusive to CANopen and specially designed for motion control scenarios.

No Uniform Object Dictionary

Pure CAN lacks a unified parameter addressing standard, leading to inconsistent instruction formats for drivers from different manufacturers. CANopen unifies the address definition of servo motion parameters via the object dictionary (DS402 standard), enabling the master station to universally control any standard servo drive.

No Event-Driven Application-Layer Linkage

SYNC, NMT and Heartbeat mechanisms trigger upper-layer application events to automatically implement synchronous motion, state switching and fault protection. In contrast, pure CAN requires manual programming of complex frame parsing, timing judgment and state management logic.

Lack of Standard Multi-Axis Synchronization Mechanism

The SYNC message is a unique CANopen feature. Pure CAN has no global synchronization reference, resulting in poor multi-axis synchronization accuracy and failure to meet the requirements of interpolation and multi-axis coordinated motion scenarios.

Understanding the Three-Layer CAN Protocol Structure (Corresponding to OSI Model)

image
image888×720 31.1 KB

(Image source: Microchip)

1. Bottom Layer: ECAN™ Driver (CAN Hardware Link Layer)

Corresponds to the physical layer and data link layer of CAN 2.0.

Core functions: Transmit and receive standard 8-byte CAN frames, implement hardware arbitration, CRC verification and bus error handling. It contains no motion control logic and cannot identify target positions, control words or synchronization instructions, serving only as a pure data transceiver. All upper-layer CANopen modules (SYNC, NMT, SDO, PDO, Heartbeat) ultimately call this driver to send CAN messages.

2. Middle Layer: Communication Sublayer (CANopen Core Protocol DS301)

Core functions of each module in motion control applications:

PDO Communications: The core of real-time motion closed-loop control. It maps motion data (control word, target position, actual position, speed) from the object dictionary. Featuring no handshake overhead and low latency, it delivers multi-axis motion commands synchronously within each SYNC cycle.

SDO Communications: The dedicated channel for motion parameter configuration. It reads and writes data in the object dictionary to configure acceleration and deceleration limits, stroke limits, motor operating modes and PDO mapping relationships during power-on initialization.

NMT Communications: Manages bus and motor safety states. It switches node states between pre-operation and operational mode. PDO-based motion control is only available in operational state, and it feeds back state switching events to upper-layer applications.

SYNC: Provides the global timing reference for multi-axis synchronization. It broadcasts synchronous messages periodically and delivers synchronization events to upper-layer application objects, ensuring all axes update position instructions simultaneously to guarantee multi-axis synchronization accuracy.

Heartbeat/Node Guard/Boot-up: Implements bus fault protection. The Heartbeat mechanism detects bus disconnection, triggers upper-layer events once communication fails, and enables the application layer to execute emergency motor stop protection.

3. Top Layer: Application Layer (Motion Control Business Logic, DS402 Servo Standard)

Object Dictionary

A unified database for all motion control parameters (standard index range: 0x6000~0x9FFF defined by DS402). It stores core parameters including 0x6040 (control word), 0x607A (target position), 0x6064 (actual position), operating modes and fault codes. SDO completes parameter configuration by reading and writing the dictionary, while PDO acquires real-time motion data via dictionary mapping.

Application Object

It executes the core business logic of motor closed-loop control and processes various events from the lower communication layer:

- SYNC events: Read target positions issued by PDO, execute position-loop PID algorithm, and output PWM signals to drive motors.

- NMT state switch events: Enable/disable motors, reset faults and complete power-on initialization.

- Heartbeat disconnection events: Trigger immediate motor shutdown for safety protection.

It feeds encoder actual position data and motor operating states back to the object dictionary for upload to the master station via PDO.

Summary

1. The ECAN Driver is a pure low-level CAN transceiver, only responsible for binary message transmission and reception, without any involvement in motion control logic.

2. The CANopen intermediate communication layer (PDO/SDO/SYNC/NMT/Heartbeat) provides standardized communication channels, precise synchronization and complete network management functions.

3. The object dictionary centrally stores all standardized motor motion parameters.

4. The top-layer application object processes layer communication events and executes core motion control algorithms including motor closed-loop operation, start-stop control and fault protection.

Reference Materials:
Microchip Application Notes

Extended Technical Topics

Why does a simple industrial control project require Modbus, CAN, and EtherCAT?