June 17, 2019
I’ve been crash coursing CANopen for work recently. In that time, I’ve learned a lot about how this communication protocol does and definitely doesn’t work. Let’s explore it a bit so we can all understand it better. Note this is just an introduction. Lets stay out of the weeds for now!
Overview
CANopen itself is a high-level communication protocol mainly used in embedded systems that is based on the Controller Area Network (CAN) protocol. In terms of the OSI model, it implements everything above and including the network layer
This means that CANopen handles everything above CAN including deciding what physical paths the data will take, maintaining a stable connection, ensuring data is in a usable format, and providing simple integration with your application.
How it implements this functionality can be summarized into a few important topics. These include the Electronic Datasheet, Object Dictionary, and Service/Process Data Objects.
Electronic Datasheets
The Electronic Datasheet is a file format that serves as an outline for what your device or node is capable doing. It is also a container for your Object Dictionary which we’ll discuss next. This can be created either manually or through automated programs such as CANopen Architect, a program offered by Embedded Systems Academy that allows automatic creation of an EDS. This software also generates header files you can include in your program to make integration of the EDS extremely simple.
The Object Dictionary
The object dictionary is a standardized structure containing all parameters describing the behavior of a CANopen node. [2] This dictionary basically contains all the data a CANopen node can share over the bus with other nodes on the network. It’s organized by items such as an index, data type, and name. When communicating with another node, you’ll have to specify the node id as well as the index value of the item in the object dictionary you want to talk to.
Service and Process Data Objects
Process data objects (PDOs) are used in CANopen for broadcasting high-priority control and status information. A PDO consists of a single CAN frame and communicates up to 8 bytes of pure application data. [3] It’s the main method of data transmission in CANopen because of how little overhead it has compared to a Service Data Object. The data transmission is fast and efficient but is mainly used only for data that’s sampled continuously like a pressure or temperature sensor reading and needs to be sent quickly. If you’re sending data with a PDO you’ll be using a transmit PDO (TPDO) and if you’re receiving, you’ll be using a receive PDO (RPDO).
Service data objects (SDOs) are a little bit different. They’re also used to access data in a node’s object dictionary, but do so with more of a client/server relationship. The protocol has a handshake and transmit method of communication. It’s slower than PDOs so is less ideal for real-time operational data but is more flexible since the packets include more information about the data being sent.
That’s about it! More in depth information about CANopen is pretty easy to find but I think this is a good overview of the most commonly used acronyms and concepts that the protocol uses.
[1] https://www.ni.com/en-us/innovations/white-papers/13/the-basics-of-canopen.html
[2], [4] https://www.csselectronics.com/screen/page/canopen-tutorial-simple-intro/language/en
[3] https://www.can-cia.org/can-knowledge/canopen/pdo-protocol/
