AutoPi Cloud
Demo Environment
AutoPi Mini 
Compare devices
AutoPi TMU CM4
AutoPi TMU SocketCAN
Asset Tracking
Big Data Project
Keyless Entry
Docker Integration
IoT Gateway
Commercial Trucking
Car Leasing
Utility Management
Vehicle Research
Supply Chain Logistics
Green Transportation
Connected Car Services
Heavy Equipment Management
Emergency Services
Automotive Cybersecurity
Public Transportation
Mobility as a Service
Car Insurance Policy
OEM Integration
Blog
API
Documentation
What can I build?
Community
Contact Support
Shop
FAQ
About us
Get in touch
Careers
Cloud Login
Welcome to our 2023 Guide to CANopen! In this post, we delve into the fundamentals of CANopen, a protocol crucial in automation and control systems. Did you know that CANopen was first developed for motion-oriented machine control systems in the early 1990s? This guide is designed to offer beginners a clear and simplified introduction to CAN-based network protocols, laying a solid foundation for understanding CANopen in various automation scenarios. Let's get started on your journey into the world of CANopen!
Whether you're completely new to CANopen or already have some expertise, this straightforward guide will provide you with all the necessary information. We've covered a range of topics to offer the clearest explanation of the CANopen protocol.
In creating this article, we pooled insights from our leading experts in the company, as well as contributions from team members who are new to CANopen.
Why this approach? Our goal was to craft a professional yet accessible introduction to CANopen, tailored for everyone, regardless of their level of experience with this crucial protocol in automation and control systems.
What is CANopen?
Simply put, CANopen is a communication protocol and device specification used in automated systems, allowing different devices to talk to each other efficiently.
CANopen, an abbreviation for "Controller Area Network, the Open Communication Solution Dissemination Project," is a protocol and device specification for embedded network systems in automation based on CAN (Controller Area Network).
Developed initially for motion-oriented machine control networks, CANopen has evolved into a standardized higher-layer protocol known for its versatility in embedded control systems. Its flexibility lies in the easy configuration of devices and its plug-and-play capability, facilitating off-the-shelf interoperability across various machines.
Today, the reach of CANopen extends beyond its original scope. It is now integral in diverse fields, including medical equipment, off-road vehicles, maritime electronics, railway systems, and building automation, showcasing its adaptability and practicality in various technological domains.
The Basics of CANopen Functionality
CANopen devices are designed with a set of standard functions integrated into their control software to ensure smooth operation within a network.
At the core of these functions is the communication unit, which handles the protocol for message exchange with other network nodes. This unit plays a crucial role in managing the device's operational states, including startup and reset, through a state machine.
The state machine transitions through various phases: from state initialization to 'before running,' then to 'running,' and finally to 'stopping.'
These transitions are controlled by sending Network Management (NMT) protocol communication objects to the device.
Key Concepts Added by CANopen Built on CAN Bus and J1939
Communication Protocols: CANopen enables efficient network communication and state machine management.
Communication Models: Utilizes Master/Slave, Client/Server, and Producer/Consumer models for diverse node interactions.
Communication Objects: Standardized in the object dictionary for easy access and organization, using a 16-bit index and 8-bit sub-index for complex data.
Object Dictionary: A crucial interface in each CANopen device, linking communication interface with application software.
Electronic Data Sheet (EDS): Defined in CiA306, it describes a device's communication behavior for accurate tool interaction.
We will delve deeper into these concepts further in the blog, but first, let's explore how CANopen relates to both CAN Bus and J1939.
Comparing CANopen with CAN Bus and J1939: A Detailed Analysis
CANopen vs. CAN Bus: Understanding the Differences
When exploring "CANopen vs. CAN Bus," it's essential to understand that while these two terms are closely related, they serve different functions in network communication.
CAN Bus: The Foundation
CAN Bus, or Controller Area Network Bus, is a robust vehicle bus standard designed to allow microcontrollers and devices to communicate with each other without a host computer. It forms the underlying physical layer and data link layer, providing the basic network infrastructure for data transmission.
CANopen: The Protocol Layer
CANopen, on the other hand, is a communication protocol and device profile specification that operates on top of the CAN Bus. It defines higher-layer protocols and includes additional features like device profiles, communication objects, and a standardized approach to configuration and diagnostics.
Key Differences: Functionality and Application
-
Layer of Operation: CAN Bus is the foundational network technology, while CANopen is a higher-layer protocol that utilizes CAN Bus for communication.
-
Complexity and Features: CANopen introduces complexity with its advanced features like object dictionaries and electronic data sheets, which are not part of the basic CAN Bus.
-
Application Scope: CAN Bus is used more broadly in various industries for simple network communications, whereas CANopen, with its specific protocols and profiles, is more suited to complex automation tasks and sophisticated device interactions.
CANopen vs. J1939: Comparing Network Protocols
In the discussion of "CANopen vs. J1939," it's important to distinguish these protocols, each significant in their respective applications and functionalities.
J1939: Tailored for Heavy-Duty Vehicles
J1939 is a protocol based on CAN specifically designed for heavy-duty vehicles, such as trucks and buses. It focuses on vehicle diagnostics, control, and communication, with a strong emphasis on robustness and fault tolerance in harsh environments.
CANopen: Versatile in Automation and Control
CANopen, while also based on CAN, extends its application beyond automotive to various types of automation and control systems. It provides a framework for interoperable devices and includes features like device profiles, state machines, and a comprehensive object dictionary.
Key Distinctions: Purpose and Structure
-
Intended Use: J1939 is primarily used in heavy-duty vehicles for diagnostics and control, whereas CANopen finds broader application in diverse automation systems.
-
Protocol Structure: J1939 has a more rigid structure tailored to vehicle networks, focusing on parameters like engine status and vehicle dynamics. CANopen offers more flexibility with its object dictionary and configurable settings, catering to a wide range of automation tasks.
-
Network Management: CANopen includes complex network management capabilities and device profile specifications, which are less prominent in J1939.
Understanding the key differences between CANopen, CAN Bus, and J1939 is essential in network communication and system design. CAN Bus lays the groundwork for network communication, while CANopen builds upon this to offer a more advanced and structured protocol. In contrast, J1939, also based on the CAN standard, is specifically designed for heavy-duty vehicles, differing from CANopen in its application focus and structural complexity. Recognizing these distinctions is crucial for effectively applying each protocol in its relevant sector.
ap into the power of AutoPi's versatile platform and craft innovative solutions in telematics.
What is CANopen Protocol?
The CANopen protocol is a complex communication system designed for automation networks, implementing a range of CANopen Communication Object Identifiers (COBs), which include a unique CAN-ID and control bits. These COBs are communicated at specific CANopen bit rates, enabling efficient data transmission across the network.
At the core of CANopen's functionality are its communication objects, which allow system designers to transmit vital control information. These objects play a crucial role in responding to error conditions, influencing, and controlling network behavior. This feature is essential for maintaining the stability and efficiency of automated systems.
Additionally, CANopen protocol supports a variety of network management functions, including node guarding and heartbeats, ensuring consistent and reliable communication among different devices in the network. It also allows for synchronous and asynchronous data transmission, providing flexibility in how data is shared and processed.
Furthermore, CANopen includes features like time-stamped messages and emergency objects, which enhance its diagnostic capabilities and overall network performance. This makes it an ideal choice for complex systems requiring precise control and monitoring.
In essence, the CANopen protocol is a robust and versatile communication framework, essential for modern automation and control systems, offering precise network management and enhanced data handling capabilities.
A Closer Look at CANopen's Protocol Range
-
PDO Protocol: Utilizes Process Data Objects for high-priority control and status broadcasting, transmitting real-time data between devices.
-
SDO Protocol: Service Data Objects enable access to and modification of CANopen object dictionary entries.
-
NMT Protocol: Network Management used for controlling device states like initialization, operational, and stopped states.
-
Error Control Protocols: Monitor CANopen network health, including heartbeat protocol for 'alive' status checks.
-
SYNC Protocol: Facilitates synchronous network activities.
-
Time-Stamp Protocol (TIME): Adjusts network time and synchronizes devices.
-
Emergency Protocol (EMCY): Notifies network of device-internal failures.
-
Guarding Protocol: Regularly checks the status of nodes to ensure network integrity.
-
Layer Setting Services (LSS): Allows for node ID configuration and querying of device properties.
-
Flying Master Protocol: Enables dynamic master selection for network flexibility.
-
CANopen Safety Protocol: Enhances network safety through additional error-checking measures.
Each of these protocols plays a vital role in the robust functionality of CANopen. In the following sections, we'll dive into the details of the most important protocols among these, so keep reading to deepen your understanding of CANopen's capabilities and applications.
Basic Principles of CANopen Communication
In a CANopen network, various devices such as industrial robot arms and other automation components communicate effectively, often coordinated by a PC or PLC. CANopen facilitates this interaction through three primary communication models, each tailored to specific network requirements and data flow patterns:
Master/Slave
-
Role: A control interface or application master controller directs slave devices.
-
Function: The master sends commands and requests data, while slaves respond accordingly.
-
Application: Used for centralized control of devices in manufacturing.
-
Service Example: Network Management (NMT) protocol, where a master device manages the state of slave devices in the network.
Client/Server
-
Role: A client node requests data or services from a server node.
-
Function: The server processes these requests and returns the necessary responses.
-
Application: Suitable for dynamic data requests in systems like building automation.
-
Service Example: Service Data Object (SDO) protocol, enabling a client (SDO client) to request data from a server (SDO server) within the network.
Consumer/Producer
-
Role: The producer node broadcasts data to the network, consumed by consumer nodes.
-
Function: Efficient distribution of data to multiple nodes simultaneously.
-
Application: Ideal for broadcasting updates or alerts across a network.
-
Service Example: Heartbeat protocol, where a producer device sends regular 'alive' status messages to consumer devices.
These communication models are essential to CANopen, ensuring smooth and efficient data exchange in various industrial and automation environments. Correct implementation of these models is key to optimizing network performance.
How CANopen Message Format Works
The CANopen frame's message format is intricately based on the structure of the CAN frame, a key aspect of the CAN protocol. Understanding the message format in CANopen is fundamental to grasping how communication is efficiently and accurately carried out within a CANopen network. Here's how it works:
-
CAN Frame Structure: In the CAN protocol, data transmission occurs through frames. These frames are composed of either an 11-bit or 29-bit CAN-ID, control bits (including the remote transfer bit (RTR), a start bit, and a 4-bit data length field), followed by a data payload of 0 to 8 bytes.
-
COB-ID in CANopen: In the realm of CANopen, this frame structure is referred to as COB-ID, which combines the CAN-ID and control bits. This identifier plays a crucial role in defining the message type and its routing within the network.
-
CAN ID Segmentation: Crucially, in CANopen, the 11-bit CAN ID is divided into two distinct segments: a 4-bit function code and a 7-bit CANopen node ID. This segmentation allows for clear message classification and precise addressing within the network.
-
Node Limitation: The use of a 7-bit node ID inherently limits the number of nodes on a CANopen network to 127. This limitation is important for maintaining network manageability and ensuring unique identification for each node.
-
Uniqueness of COB-IDs: To avoid any communication conflicts on the bus, it’s essential that each COB-ID within the network is unique. This uniqueness is fundamental to the efficient and error-free operation of the network.
-
SDO Communication Protocol: In the context of Service Data Object (SDO) communication, a key principle is that only one node should access the individual object dictionary indices of the slave nodes at any given time. This ensures orderly communication and avoids data conflicts.
CANopen within the OSI Model Framework
As we look into how CANopen fits within the OSI Model Framework, it's essential to recognize its role as a higher-layer protocol built upon the CAN bus.
The CAN bus system covers the first two levels of the OSI Model, while CANopen extends this framework into the higher layers, integrating key standards and specifications from CiA (CAN in Automation) and ISO (International Organization for Standardization)
-
Network Layer: This layer is responsible for addressing and routing, ensuring that data is correctly directed across the network.
-
Transport Layer: It ensures end-to-end reliability of data transmission, managing the integrity and sequencing of the data packets.
-
Session Layer (CiA 303-1): This layer handles synchronization, coordinating communication sessions between devices.
-
Presentation Layer (CiA 303-2): It standardizes data encoding and representation, ensuring that the data is universally understandable across different systems.
-
Application Layer (CiA 401, 402, ...): The topmost layer, where CANopen specifies how devices are configured, data is transmitted, and activities are synchronized.
These layers, governed by CiA and ISO standards, enhance CANopen's functionality within the OSI Model, ensuring robust network management, data reliability, and effective communication in automation systems.
The Basics of the CANopen Application Layer
In this section, we delve into the fundamental concepts underpinning the application layer of the CANopen protocol. This exploration is crucial for understanding how CANopen manages and facilitates high-level data interactions and device functionalities within a network.
Object Dictionary
At the heart of CANopen's application layer is the object dictionary (OD), a key component for all CANopen devices:
-
What It Is: The OD is a structured table that stores both process data and configuration settings, helping to define how a CANopen node operates.
-
Structure: It has a 16-bit index and an 8-bit sub-index, allowing for a large number of unique entries (up to 65,536 indices and 256 subentries for each index).
-
Standard Parameters: Specific indices in the OD are reserved for standard parameters, like the device name, making it easier to identify devices in a network.
-
Mandatory and Optional Entries: Some indices are required for all CANopen devices (like the device type), while others are optional (like software version).
-
Using the Object Dictionary: Devices use the OD to perform functions (like starting data acquisition), and masters use it to read data or check device settings.
-
Accessing the OD: The OD is accessed through Service Data Objects (SDOs) and Process Data Objects (PDOs), which are ways to read from and write to the dictionary.
-
Data Types: The OD contains basic data types (like integers and Boolean values) and can also handle more complex types, like strings or custom CANopen-specific types.
The OD is crucial in managing CANopen devices, ensuring organized, standardized, and efficient network operations.
Join the revolution in vehicle telematics by developing with AutoPi's open platform. Create cutting-edge applications today!
Service Data Objects (SDO)
Service Data Objects (SDO) play a crucial role in CANopen networks, facilitating the communication between the master and nodes:
-
SDO Servers and Clients: Each node in a CANopen network acts as an SDO server, handling data requests. The CANopen master functions as the SDO client, initiating data requests.
-
How It Works: The SDO client (master) sends a request to a specific node (server). This node then responds with the requested data. This interaction uses unique CANopen message IDs for each node.
-
Message IDs: For an SDO request, the client uses a CAN-ID formed by adding 600h to the Node ID. The server responds with a CAN-ID formed by adding 580h to its Node ID.
-
Data Transfer Types: There are two main types of data transfers in SDO communication:
-
Segmented Transfer: Used when data is too large for a single message, requiring multiple segments.
-
Expedited Transfer: All data is sent in a single message, used for smaller data sizes.
This SDO communication mechanism ensures orderly and efficient data exchange within CANopen networks, essential for the proper functioning of automated systems.
Process Data Object
Process Data Objects (PDOs) are essential in CANopen for handling real-time data, like sensor inputs or motor drive outputs:
-
Process Data and Object Dictionary: Process data, constantly changing over time, is stored in the object dictionary. However, accessing this data using SDOs, which can only handle one index at a time, can be inefficient for fast-changing data.
-
Autonomous Data Transmission: CANopen protocol requires that nodes must send their own data autonomously, without waiting for a request from the master. This is where PDOs come into play.
-
PDO Types:
-
Transmit PDOs (TPDOs): Data produced and sent by the node.
-
Receive PDOs (RPDOs): Data received and consumed by the node.
-
-
PDO Parameters: PDOs have two main types of parameters – configuration and mapping. These are stored in specific sections of the object dictionary (indices 1400h-1BFFh).
-
Configuration Parameters: Include the COB-ID, transmission type, inhibit time (for TPDOs), and event timer. These parameters define how and when PDOs are transmitted.
-
Transmission Methods: PDOs can be sent in several ways:
-
Event-Driven: Triggered by changes in the process data.
-
Time-Driven: Occur at set time intervals.
-
Synchronized Polling: Initiated by a SYNC signal, allowing simultaneous data snapshots from multiple nodes.
-
PDO communication in CANopen is designed for efficiency and real-time responsiveness, crucial for managing dynamic data in automated systems.
