Technical Data

CANopen is a communication protocol and device profile specification for embedded systems used in automation. In terms of the OSI model, CANopen implements the layers above and including the network layer. The CANopen standard consists of an addressing scheme, several small communication protocols and an application layer defined by a device profile. The communication protocols have support for network management, device monitoring and communication between nodes, including a simple transport layer for message segmentation/desegmentation. The lower level protocol implementing the data link and physical layers is usually Controller Area Network (CAN), although devices using some other means of communication (such as Ethernet Powerlink, EtherCAT) can also implement the CANopen device profile.

The basic CANopen device and communication profiles are given in the CiA 301 specification released by CAN in Automation.

Source: Wikipedia

Applicable Specifications

CANopen Application Layer and Communication Profile, CiA Draft Standard 301, Version 4.02, Date: 13 February 2002
Robert Bosch GmbH, CAN Specification 2.0 Part B, September 1991

The data below applies to CANopen Slave firmware and stack version 5.x.x.x The firmware/stack has been designed in order to meet the CiA Work Draft 301 V4.2.0 specification.

Key Features

Node guarding / life guarding and heartbeat
- producer
- max. 8 consumer
PDO mapping
NMT Slave
SYNC protocol (consumer)

Feature	Description
number of input data	standard mode default setting: 128 bytes, extended mode: maximum 1020 bytes
number of output data	standard mode default setting: 128 bytes, extended mode: maximum 1020 bytes
number of receive PDOs	standard mode default setting: 16 extended mode: 0..512, for mapping objects 2200 … 2203
number of transmit PDOs	standard mode default setting: 16 extended mode: 0..512, for mapping objects 2000 … 2003
Exchange of process data	Via PDO transfer synchronized remotely requested event driven (change of date) Requested by application via packet
Acyclic communication	SDO Up- and Download (Server only), Emergency message (producer), Timestamp (producer/consumer)
Functions	Node guarding / life guarding, heartbeat PDO Mapping NMT Slave SYNC protocol (consumer) Error behavior in state operational: change to state pre-operational no state change change to state stopped
Baud rates	10 kBit/s to 1 MBit/s Automatic detection
Data transport layer	CAN Frames
CAN Frame type	11 Bit

*: In extended mode, the stack offers extended functionality. To use these functions requires an application program that configures and supports these functions, e.g. to create an own object dictionary. In extended mode, more input and output data can be used and transmit and receive PDOs can be used.

Note: The actual maximum number of IO Data and PDOs depends on the available amount of memory.

Configuration

Packet API based configuration by host application
Data base configuration (config.nxd) created by configuration tool

Diagnostic

Dual-port memory: Common diagnostic via dual port memory
API: Packet API bases diagnostic
LED: Diagnostic LED

Firmware Functions

The CANopen Slave protocol stack is fully integrated into a netX firmware for specific use case in order to provide a common set of netX firmware functions accross different protocol variants:

Firmware Variants	Use Case A	Use Case B	Use Case C
Use Case summary	netX90 COM CPU firmware for small footprint, low cost and function optimized slave devices no external SPI / SQI Flash required for COM CPU no external SDRAM required for COM CPU	same as Use Case A, but netX90 APP CPU uses external SPI Flash may use external SDRAM	full featured firmware for highest function requirements external SDRAM is required for COM CPU external SPI Flash is required for COM CPU
netX support	netX90	netX90 with ext FLASH	netX90 with ext SDRAM and ext FLASH
FW structure	TBD		TBD
Host Interface	Dual Port Memory interface with following channels: Channel 0 - CANopen Slave Protocol API exchange cyclic IO data use acyclic protocol services
Diagnostic Interface	netX Diagnostic and Remote Access is supported via netX90 COM UART
Integrated Flash File System	N/A	N/A	Power-fail safe flash file system on external SPI flash is used
Remanent Data Storage	Power-fail safe storage of up to 16KB of protocol remanent data in netX90 internal flash		Power-fail safe storage of protocol remanent data in dedicated partition in extenal SPI flash. Size and position of remanent storage area shall be configured in FDL.
Device Data	device production data (Serial number, MAC address, production data etc.) shall be stored in FDL in:
Device Data	netX90 internal flash		netX90 internal flash
Firmware Transfer	via Host Interface (DPM, SPM) due to limited size (max. 380KB) of FW update area in internal flash, only following files can be transfered: individual firmware files (i.e. comfw.nxi or appfw.nai) if the size of the a file is less that 380KB max. 380KB big FWUPDATE.zip file with predefined structure	N/A	to netX flash file system located on external SPI Flash
Firmware Update	Firmware check and installation supported through calling the Maintenance Firmware Note: netX90 Use Case C firmware requires Maintenance Firmware v1.3.0.0 or later.
Firmware Update	from internal netX90 flash	N/A	from Flash File System located on external SPI Flash
Configuration	by sending configuration packets to the firmware via Host Interface
Configuration	N/A		or by using Communication Studio configuration database file from local flash file system
Tag List Options	Firmware supports certain modification of the functionality via Tag List
HW Sync Signal	N/A
Protocol Specific LED Indicators	Network specific status indicators with COM0 / COM1 LEDs: Diagnostic LED
Secure Boot	supported by CANopen Slave V5.2.0.0 and later, see Support of Secure Boot with netX90 for more details
Limitations	FW functions are limited by available internal RAM / Flash COM firmware size is limited to max. 500KB	FW functions are limited by available internal RAM / Flash COM firmware size is limited to max. 880KB