Get Your CANopen-er Gear Today!

CANopen is the only industrial protocol in which devices are not strictly peer-to-peer and not strictly master-slave. The whole point is to eliminate the need for a single master or main controller to take care of everything. Each message that is sent has a priority, and higher priority messages trump lower priority ones (which wait until there isn’t a high priority message being sent). It’s kind of similar to a peer-to-peer network in that it’s decentralized, which reduces failure points. For that reason, I consider myself a CANopen-er (trademark pending) and I’m contemplating making t-shirts. After reading this overview of CANopen, you might want one, too.

Data Structure

Built on the standard CAN (Controller Area Network) physical communications standard, CANopen is an object-based communications protocol, which means that an object dictionary describes the complete functionality of a device. The object dictionary is the connection point between the communication interface and the application program. All communication objects are described in the object dictionary in a standardized way.

The CANopen object dictionary provides standardized communication objects for real-time data, configuration data and special functions as well as network management data. There are also explicit and implicit messages embedded in the CAN application layer, which allows access to the object dictionary. Explicit messages allow a device to request the data value of a specific item in the object dictionary or set the value of an item in the object dictionary. Implicit messages allow predefined data transfers from one device to another without any overhead.

Message and Data Types

Process Data Objects (PDO)
PDO data transfers are of great priority. The purpose here is to move I/O and high-priority status information from one device to another. They are the most common method for two devices to exchange data and can be initiated internally by a device or via some sort of external message.

Service Data Objects (SDO)
SDOs support the transfer of asynchronous commands and data between two CANopen devices. They exist primarily for configuration, though some vendors seem to like to use them for data transfer. The target of the SDO message, the object dictionary that is acted upon, is the server for the SDO and the initiator is the client.

SYNC Messages
SYNC messages essentially do one thing, and one thing only: synchronize the actions of a group of CANopen devices. CANopen reserves a connection ID in the highest priority group (lowest CAN ID) to ensure that the SYNC message is reliably transmitted over the network.

NMT Messages
NMT messages are what a master device uses with a set of CANopen slave devices that implement the predefined connection set. The NMT command includes a command byte which indicates the action to perform, as well as the node ID. The node ID of 0 indicates that all devices in the network should indicate the command.

Emergency Messages
You will never guess what these are about, so I’ll just tell you. Emergency messages are those that contain the emergency data object in the event of an internal device error. This prevents additional messages from being transmitted unless the internal error condition is raised. It is usually a master device that will receive the emergency message.

By now, I assume that you are literally jumping out of your seat with excitement. I mean, why wouldn’t you be? You’re probably ready to order your officially licensed CANopen-er t-shirt, Unfortunately, we don’t have any t-shirts (we’re still waiting on the trademark). However, we do have a ridiculous amount of CANopen knowledge that we’ll share when you reach out to us. You can also reach us at 1-800-249-1612.