Scope

This IG coordinates the development, release, and maintenance of CANopen CC (classic) technical documents related to the application layer, the physical layer as well as additional services and protocols.

Chair

Martin Rostan, Beckhoff

Meetings

There are no events in the current view.
Name Date Size Action
IG01 CANopen 2017-12-12 3 MB Login
IG01 CANopen 2015-12-10 3 MB Login
IG01 CANopen 2016-12-13 3 MB Login
Title Details
Published
Size
Status
Action
CiA 303-1 version 2.0.1 Device and network design - Part 1: CANopen physical layer
Scope

This document provides device and network design recommendations for the CANopen physical layer. Additionally, it provides guidelines for selecting cables for use in CANopen systems.

2023-03-27 217 KB TR Login
CiA 305 version 3.0.0 CANopen layer setting services (LSS) and protocols
Scope

This document specifies the layer setting services (LSS) and protocols for CANopen. These services and protocols are used to inquire or to change the settings of three parameters of the physical layer, data link layer, and application layer on a CANopen device with LSS slave capability by a CANopen device with LSS master capability via the CAN network. The following parameters may be inquired or changed: • Node-ID of the CANopen device; • Bit timing parameters of the physical layer (bit rate); • LSS address compliant to the identity object (1018h)

2013-05-08 2 MB DSP Login
CiA 306 version 1.3.0 CANopen electronic data sheet (EDS)
Scope

The usage of devices in a communication network requires configuration of the device parameters and communication facilities. CANopen defines a standardised way to access these parameters via the object dictionary. For handling of the complexity of CANopen systems software tools are required. This reduces the complexity of the planning, configuration and analysis process and significantly increases the security of the system. For this purpose software tools need an electronic description of the CANopen devices. To allow the usage of manufacturer independent tools, this document defines a standardised file format – called Electronic Data Sheet. Furthermore some derived file formats are specified. The Device Configuration File describes a concrete incarnation of a device configuration. The Module Data Sheet describes modules of devices with a modular structure

2005-01-01 359 KB TR Login
CiA 306-1 version 1.4.0 CANopen electronic device description - Part 1: Electronic data sheet (EDS) and device configuration file (DCF)
Scope

This set of documents specifies the electronic description of CANopen devices in harmonized file formats such as electronic data sheet and device configuration file, which are used to configure CANopen device parameters as well as for testing and diagnostic pu rposes. This set of documents consists of the three parts: ⎯ Part 1: Electronic data sheet and device configuration file; ⎯ Part 2: Profile database; ⎯ Part 3: Network variable handling and tool integration. This part of the document specifies the electronic dat a sheets as well as the device configuration files. Additionally, it specifies CANopen Safety device entries for EDS and DCF in the Annex A, the relationship between object attributes and EDS (DCF) keynames in the Annex B, and EDS examples in the Annex C. The specification of an XML-based CANopen device description is not in the scope of this set of documents.

2019-08-01 687 KB DSP Login
CiA 306-2 version 1.2.0 CANopen electronic device description - Part 2: CANopen profile database (CODB)
Scope

This set of documents specifies the electronic description of CANopen devices in standardized file formats. These electronic descriptions are used to configure CANopen device parameters or for testing and diagnostic purposes. This set of documents consists of the three parts: ⎯ Part 1: Electronic Data Sheet and Device Configuration File; ⎯ Part 2: Profile database; ⎯ Part 3: Network variable handling and tool integration. This part specifies the CANopen profile database format, which is used by tools (e.g. EDS file checker). The specification of an XML-based CANopen device description is not in the scope of this set of documents.

2019-08-01 759 KB DSP Login
CiA 306-3 version 1.2.0 CANopen electronic device description - Part 3: Network variable handling and tool integration
Scope

This set of documents specifies the electronic description of CANopen devices in standardized file formats. These electronic descriptions are used to configure CANopen device parameters or for testing and diagnostic purposes. This set of documents consists of the three parts: ⎯ Part 1: Electronic data sheet and device configuration file; ⎯ Part 2: Profile database; ⎯ Part 3: Network variable handling and tool integration. This part specifies mechanisms with regard to the handling of network variables, which are specified in CiA 302-4. In addition recommendations for tool integration are provided. NOTE This document contains parts of the withdrawn document CiA 405.

2019-08-01 431 KB DSP Login
CiA 308 version 1.0.1 CANopen performance measurement basics
Scope

CANopen is a field-bus protocol used in many diverse application: CANopen networks can be found not only in various industrial applications ranging from printing machines and robots to process controls, but also in ships, building automation, trains, trucks and even in coffee machines. CANopen is used for high accuracy drive synchronisation and for flight data recording. It is also in use in medical applications and has been chosen as the standard communication protocol for passenger information systems in public transport. This variety of applications leads to totally different requirements in regard to CANopen performance. The critical real-time requirement of one application may be a short response time to synchronisation messages relating to a single process data object, where as a different application may expect a node with many event driven process data obj ects to send these objects immediately after a certain input signal has changed. With drive synchronisation for instance, some applications need long time accuracy of the sync cycle and tolerate almost any jitter of a single sync message, and others require minimal jitter and tolerate long term drift. Regarding most other bus systems it is fairly straightforward to measure and publish communication performance figures for most node types. With CANopen this is not the case: the capability of CANopen to tailor the communication to the application needs makes it very difficult to determine valuable performance figures that are independent of the specific network set-up. For example, figures relating to reaction times not only depend on the processor used, but on the actual bus load, on the type of CAN controller being used, on the actual number and types of I/Os or drives connected, on the number and transmission types of the process data objects, on the guard or heartbeat cycle, and on many other settings and parameters in the object dictionary. Developing a CANopen node always involves a certain trade-off between performance and functionality. Therefore performance is a multi - dimensional value. The goal of this performance specification is to name and define a set of CANopen communication performance figures that may be used to compare devices and implementations within a specific application environment. It is not the aim of this paper to define a standard performance-measuring environment, as this would lead to implementations that perform fine in exactly this environment but disappoint under most other conditions. However, in order to establish some comparable conditions, this specification defines a number of standard busloads that may be used to simulate or enhance application environments. This performance test specification is aimed both at CANopen device developers and at CANopen system integrators. It may help developers determine relative performance figures regarding two implementation variants, thus leading to better devices and it may help system integrators to ask the right questions, thus leading to better CANopen networks.

2006-01-24 1 MB TR Login
CiA 314 version 1.0.0 Accessing CANopen services in devices programmable in IEC 61131-3 languages
Scope

This document specifies function blocks to produce or consume CANopen communication services for devices programmable in IEC 61131-3 languages and to provide local CANopen functions. This specification is suitable for programmable logic controllers (PLCs), PC-based controllers running a PLC-software, and other programmable devices compliant to IEC 61131. NOTE This specification substitutes the CiA 405 document those content has been moved to different documents (CiA 302-4 and CiA 306-3).

2015-10-09 342 KB DSP Login
CiA 315 version 1.0.0 CANopen generic frame for wireless tunneling and for transfer of diagnostic data
Scope

This specification specifies the generic frame for the transparent transmission of CAN messages on a wireless network.

2011-08-09 626 KB DSP Login
CiA 320 version 1.0.0 CANopen services and protocols for sleep and wake-up handling
Scope

This document specifies services and protocols for sleep and wake-up handling. It considers CANopen devices that use CAN transceivers with low-power mode or selective wake-up capability, as well. CANopen sleep and wake-up handling are implemented in e.g. light electric vehicles, add-on modules for special purpose cars, service robots, or any other application that operate on a limited amount of energy and in which energy management is therefore essential.

2018-03-14 998 KB DSP Login
CiA 801 version 1.0.0 CANopen automatic bit-rate detection
Scope

This technical report describes the recommended practice and gives application hints for implementing automatic bit-rate detection in CANopen devices. With the Layer Setting Services (LSS) it is possible to change the bit-rate in CANopen networks. However, this mechanism fails in certain situations. Some low-cost devices that do not support LSS at all could also benefit from the recommended automatic bit-rate detection method. This technical report discusses an approach for automatic bit-rate detection in CANopen networks. As introduction the possible solutions to detect an unknown bit-rate for CAN controllers (Software / Hardware) are presented. The technical report will focus on situations where automatic bit-rate detection fails (no traffic on the bus, error frames) and how to avoid these deadlocks.

2005-01-01 334 KB TR Login
CiA 802 version 1.1.1 Avoiding CAN Remote Frames in CANopen networks
Scope

This document provides recommendations for avoiding CAN Remote Frames when using CANopen communication services.

2021-02-10 366 KB TR Login