Applicable to standardized embedded networks, what is the difference between CAN

CANopen is a high-level communication protocol built on the Controller Area Network (CAN), which includes communication and device sub-protocols. It is commonly used in embedded systems and is a widely utilized fieldbus in industrial control.

Based on CAN, CANopen defines communication rules for the application layer, making it particularly suitable for embedded networks that require standardized device configuration and network management.

Introduction to CANopen Protocol

 

The international standard ISO 11898-2, published in 1994, defines the physical layer and data link layer of the CAN bus. CANopen builds upon this foundation with higher-level protocols, which have since been widely applied in industrial automation, automotive electronics, and other fields.

Advertisement

CANopen implements the agreements above the network layer (including the network layer) in the OSI model, including addressing schemes, several small communication sub-protocols, and the application layer defined by device sub-protocols. Therefore, CANopen and CAN are two distinct communication protocols; CAN is a lower-level communication protocol, while CANopen belongs to CANBUS, which is a high-level protocol of the CAN bus, providing higher-level functions such as device configuration, network management, and data transfer protocols.

The difference in functional layers between CAN and CANopen is the most intuitive. The advanced communication functions provided by CANopen include network management (NMT), Service Data Object (SDO) transfer, and Process Data Object (PDO) transfer. These are suitable for applications in complex systems such as industrial automation, medical equipment, and marine vessels that require coordination among multiple devices.

To date, CANopen has established many advanced protocols, the most important of which are the CiA DS (Device Specification) and DS301/DS302 standards. DS301 defines the basic characteristics of the CANopen protocol, while DS302 defines the specific requirements for CANopen devices.

Additionally, CANopen has introduced some key technical details. For example, the Object Dictionary is a crucial component within CANopen; both CANopen and devices require an Object Dictionary for setting device configurations and conducting non-immediate communications. Each object in the Object Dictionary corresponds to a 16-bit index and an 8-bit sub-index (some objects have no sub-index, or the sub-index is considered to be 0), and its attributes include whether it is readable and writable. The length of the Object Dictionary can be 8-bit, 16-bit, or 32-bit. Furthermore, the Object Dictionary not only contains the device's configuration parameters but also includes real-time data and error history records of the device.

Another example is the Process Data Object (PDO), which is used for rapid access to the Object Dictionary and serves a similar purpose to the SDO, but with a different implementation method. SDO requires specifying the index and sub-index of the Object Dictionary that needs to be read or written each time a message is sent, allowing flexible access to any Object Dictionary. Meanwhile, the SDO response message ensures the accuracy of data transmission.Additionally, the technical details of CANopen also include the requirement for SDO messages to be acknowledged, NMT network services, and SDO communication, etc.

CANopen Solutions

In the field of industrial automation, CANopen is primarily used for device communication and control in industrial robots and automated production lines. Currently, there are a plethora of options for both hardware and software solutions for CANopen.

First, let's take a look at the SYS TEC CANopen Chip F40 from HONGKE HK, which is a plug-and-play, cost-effective single-board computer that includes the latest pre-programmed CANopen firmware. The CANopen Chip F40 offers a simple and cost-effective DIP40 connector interface for connecting to target peripherals and converting the CANopen chip into a universal communication interface. Engineers can implement CANopen slave devices based on the CANopen Chip F40, in accordance with the CANopen device profile sub-protocol 401 and the CANopen communication sub-protocol 301 V4.02. Two LED indicators show the device status, in line with 303-3 V1.0.

Next, consider the CANopen absolute value industrial encoder SAS/M58 from SIVIDE. It utilizes highly accurate magnetic sensing technology, supporting both single-turn and multi-turn encoders, and communicates via the CANopen bus with a maximum transmission rate of up to 1MHz. Additionally, this encoder also supports the addition of incremental signal TTL or HTL outputs, enriching the signal output options. In terms of resolution, the single-turn resolution can reach up to 21 bits, and the multi-turn count can reach up to 14 bits, with exceptional shock and vibration resistance and a protection rating of up to IP68. The encoder also features anti-reverse and short-circuit protection functions, effectively reducing the impact of installation errors on the encoder. It is particularly worth noting that the SAS/M58 is 100% domestically produced.

Then, there is the GCAN-IO series of CANOPEN custom gateway products from Guangcheng Technology, which are industrial fieldbus IO modules. These modules are standard slave devices that communicate with the master device using either CANopen or Modbus protocols. Users can control the digital/analog output status of the GCAN-IO modules using CANopen or Modbus master devices and can also read the digital/analog input status of the module in real-time using the master device.

Of course, hardware alone is not sufficient. To effectively use CANopen, software support is also necessary. In practice, appropriate software tools are used to configure/manage complex CANopen networks. There are numerous free CANopen software tools available online, and companies like HONGKE HK also provide specialized development tools and software packages.

Conclusion

 CANopen defines more advanced functions on the basis of CAN, including network management (NMT), service data object (SDO) transfer, process data object (PDO) transfer, etc. It also introduces technical details such as the need for SDO message acknowledgments, NMT network services, and SDO communication, making it very suitable for standardized embedded networks.