1. Historical Origins of the Two
CAN was originally designed by the German company BOSCH for automotive control systems and became an international standard in 1993. Due to its high reliability and good error detection capabilities, it has gained attention and has now expanded into various fields such as medical, transportation, motion control, and industrial automation.
CANopen is the application layer of CAN. It was first introduced in 1995 by the European CIA association with its initial standard version, which has been continuously improved in application over the next five years. The main standard currently in use is the 1999 revision.
2. Why CANopen is Necessary
Since CAN did not define a standard application layer at its inception, manufacturers have different definitions of the application layer in practice. This leads to different functional meanings for the same CAN message due to varying interpretations by the application layer, preventing direct communication between devices and hindering compatibility among CAN network devices from different manufacturers. To address this, the CIA association was specifically established in Europe to promote the CANopen application layer. Additionally, CANopen has developed PDO messages specifically for devices that require synchronization and real-time control, greatly improving message transmission efficiency. Compared to DeviceNet (another application layer standard of CAN), CANopen messages are simpler and more open, making CANopen more worthy of promotion.
In fact, standardizing the message format and its implementation (communication layer) is not enough; it is also necessary to unify the correspondence between message parameters and device functional parameters. For example, if the parameter for setting frequency in a variable frequency drive does not correspond to a specific parameter in the message, users will still be limited to a specific manufacturer’s device due to differing definitions. Therefore, the CIA has defined standards for various types of devices, such as the CIA 406 standard for encoders, the CIA 401 standard for various I/O modules, and the CIA 402 standard for motion control drive devices. As long as the devices purchased by users comply with these standards, there is no need to worry about compatibility or communication issues with devices from other manufacturers. This means that the same message command can achieve the same function across devices from different manufacturers, truly making it vendor-independent. This is also a major reason why CANopen has greater potential.
3. Can CANopen Messages Be Sent and Received Using CAN Cards or USB-CAN?
Just as a third-party telegraph machine can receive telegrams sent by others, ordinary CAN interface boards (such as PCAN-PCI) or USB-CAN (PCAN-USB/CANUSB/CAN232) can normally receive various CANopen messages. However, understanding the specific meanings requires knowledge of the CANopen message format specifications, similar to using a codebook to decipher telegrams in wartime. Similarly, users can write CANopen messages according to the specifications and send them to other standard CANopen devices. Additionally, since PDO messages require pre-configuration for both sending and receiving ends, CAN interface devices cannot directly send PDO messages. To parse and send CANopen messages, tools like PCANopen Magic or CANreport can be used, including quickly importing and modifying device EDS files.
4. Can Software Supporting CANopen Parsing Detect Node Information Sending CAN Messages?
Some CANopen software cannot recognize the meanings represented by CAN messages and thus cannot identify nodes that only support the CAN protocol. (Note: It can only recognize nodes that have the standard CANopen protocol implemented, while CAN nodes without the CANopen protocol in the application layer are often unrecognized.) Additionally, there is no unified standard for CAN message protocols, allowing each device manufacturer to define their own CAN protocols. Thus, all devices from the same manufacturer can recognize and communicate with each other, but if a device fails and needs to be inspected or replaced, it is limited to that manufacturer because the meaning of the CAN message is defined by them. Even if users can capture the message using USB-CAN, it requires substantial effort and time to analyze the functionality of each message. In contrast, with standard CANopen messages, these issues are alleviated, which is also a reason for the rapid development of CANopen in recent years.
5. Does Adding CANopen on Top of CAN Increase Message Transmission Time?
This is not a concern. CANopen code is typically written by experienced manufacturers and validated by the CIA and practical applications. The PDO functionality developed specifically for CANopen for multi-axis synchronized control and other real-time requirements has also proven not to affect message execution real-time performance. Furthermore, compared to the scattered manufacturers writing their own application layers (assigning their own functional meanings to CAN message formats), CANopen is not only comprehensive (covering device status detection, error reporting, and network management messages), but also the implementation methods of various messages are the result of collaborative research by multiple parties in Europe, leading to higher message implementation efficiency.
Generally, factors that affect the real-time performance of CANopen devices depend more on the rationality and standardization of the written CANopen source code. Additionally, the quality of the written CANopen source code greatly impacts the stability and reliability of the devices. How to write efficient and high-quality source code, or how to choose mature source code that is easy to port in the market? For more information about CAN/CANopen solutions and services (CAN analyzers, CANopen analyzers, CANopen protocol stack source code, custom CANopen protocol stacks), please contact: Guangzhou Hongke Electronics Technology Team: [email protected] Free hotline: 400-999-3848; for more technical materials.