1、CANopen‘s Predefined MessageID Classification:
At the inception of CANopen, even in the automotive electronics industry where CAN bus is most widely used, the number of CAN nodes in the network and the amount of information needing communication were relatively low. People adopted CAN to replace RS485, primarily valuing its real-time advantage of burst transmission, while in multi-node, long-distance applications, CAN bus does not have an advantage over RS485; for instance, at the same baud rate, the communication distance of CAN can only reach 0.6-0.8 times that of RS485, and multi-node communication with CAN cannot perform arbitrary burst transmissions, having to follow the polling communication mechanism like RS485, otherwise it will lead to congestion, as shown in Figure 4.1. Just like cars at this intersection, if there are only 10 cars, even without traffic lights, there will be no congestion. However, if there are 100 cars, driving arbitrarily will cause severe congestion.
CAN‘s burst advantage and multi-point congestion
The founder of CANopen is very familiar with the characteristics of CAN bus, so when designing CANopen, it was defined as small networks and control signals for real-time communication:
1 Message transmission uses the CAN standard frame format, which is an 11bit ID field to minimize transmission time;
COB-ID
2. Network control messages use the minimum number of data bytes. For example, the heartbeat message has only 1 byte of data;
3. Real-time updated process data does not require a response from the receiving message. It adopts a producer-consumer model to reduce bus load;
4. Configuration parameters requiring confirmation from the receiver generally use fast single-word transmission. That is, 1 message can transmit a maximum of 1 32 byte parameter variable, avoiding the real-time reduction caused by frame segmentation.
All these definitions are aimed at saving time costs and maximizing real-time assurance. To reduce the configuration workload of simple networks, CANopen defines mandatory default identifier (CAN frame ID) allocation tables to minimize the learning time for users and maintainers, allowing for quick onboarding.
2、Network Management and Special Protocol MessageID Classification
Although CANopen communication leverages CAN features, where all nodes have equal communication status and can send messages autonomously during operation, the CANopen network requires the establishment of a network management host NMT-Master (Network Management Master) for stable, reliable, and controllable operations, akin to a conductor of a symphony orchestra, where all nodes’ start and stop commands are conducted by it, as shown in the figure.
NMT-master is like the conductor of a symphony
NMT Master is generally a PLC or PC with monitoring capabilities in the CANopen network (of course, it can also be a general functional node), hence also referred to as the CANopen master station. The corresponding other CANopen nodes are referred to as NMT slaves(NMT-slaves).
NMT Master and NMT Slave communicate through messages known as NMT network management messages. Management messages are responsible for layer management, network management, and ID allocation services. For instance, initialization, configuration, and network management (including node protection). In network management, only one master node is allowed in the same network, with one or more slave nodes, adhering to the master-slave model.
Additionally, to coordinate various nodes’ synchronization, heartbeat, time, and error notifications, CANopen has defined a series of special protocols (Special protocols) messages. As shown in the table, these are CANopen‘s predefined messages (Pre-defined CAN-IDs) for NMT messages and special protocol messages.
NMT and special protocol CAN-ID definitions
CAN-ID refers to the COB-ID of such messages, where readers must remember the meanings of these commonly usedCAN-ID with a green background. In the development and application of CANopen, these three categories are the most commonly used NMT and special protocol messages.
This article is reprinted from Guangzhou Zhiyuan (original authors Zhou Ligong, Huang Minsi)