The CANopen
Library provides all required services for a CANopen
compliant communication according to the communication
profile CiA 301 V 4.1. It facilitates easy
and fast development of master and slave devices and is able
to serve one or multiple CAN-Controller in one device.
The CANopen Library is available in different
expansion stages:
- Slave Small
- Slave
- Master/Slave
The functional range can be extended by additional modules (LSS, Redundancy, Flying Master, CANopen safety, ...) (see CANopen-Library Extension modules).
Access to the hardware is carried out via a defined driver interface, which is available for many CPU- and CAN controller with and without operating system (see CANopen Driver Package).
The CANopen Library is based on ground of the communication profile CiA 301 V4.1 of the CiA e.V. "CANopen Application Layer and Communication Profile" and EN50325-4 , respectively, and provides all services specified therein. It is completely written in ANSI-C and can be compiled with every ANSI-C compliant compiler.
Depending on the
required scope of functionality the CANopen Library
is available in different expansion stages. For development
of small sensors and actuators with limited CAN- open
services the Slave Small-Version is available. Its
limitations are composed of a restricted number of service
instances and no support for the CANopen services SYNC and
TIME.
With the Slave-Version of the CANopen
Library all services are provided for development of
full-featured slave devices.
The functionality of the
network management master as well as the comfortable node
monitoring functionality is provided by the
Master/Slave-Version, which of course contains the
services of the Slave-Version.
Additional services of other communication profiles (CiA 3xx) are provided by means of extension modules.
All versions of the CANopen Library are compatible to each other and are constantly tested with the
current CANopen Conformance Test for compliance with the standard.
|
Slave Small |
Slave | Master/ Slave |
Extra Package |
||||||
| SDO Server | 32 | 128 | 128 | ||||||
| SDO Client | 128 | 128 | |||||||
| SDO Segmented Transfer | √ | √ | |||||||
| SDO Block Transfer | √ | ||||||||
| Dyn. SDO Slave | √ | ||||||||
| SDO Manager | √ | ||||||||
| Program Download | √ | √ | |||||||
| PDO Consumer | 64 | 512 | 512 | ||||||
| PDO Producer | 64 | 512 | 512 | ||||||
| Dynamic Mapping | √ | √ | |||||||
| Bitwise Mapping | √ | √ | |||||||
| MPDO Source Mode | √ | ||||||||
| MPDO Dest. Mode | √ | ||||||||
| Nodeguarding Master | √ | ||||||||
| Nodeguarding Slave | √ | √ | |||||||
| Lifeguarding | √ | √ | |||||||
| Heartbeat Consumer | 128 | 128 | |||||||
| Heartbeat Producer | √ | √ | √ | ||||||
| EMCY Consumer | 128 | 128 | |||||||
| EMCY Producer | √ | √ | √ | ||||||
| Time Consumer | √ | √ | |||||||
| Time Producer | √ | ||||||||
| SYNC Consumer | √ | √ | |||||||
| SYNC Producer | √ | ||||||||
| NMT Slave | √ | √ | √ | ||||||
| NMT Master | √ | ||||||||
| NMT Flying Master | √ | ||||||||
| Bootup Procedure | √ | ||||||||
| Configuration Manager | √ | ||||||||
| LED Indicator | √ | √ | √ | ||||||
| Safety Communication | √ | ||||||||
| Redundancy Support | √ | ||||||||
| LSS Services | √ | ||||||||
| CiA 401 Framework | √ | ||||||||
| CiA 402 Framework | √ | ||||||||
| CiA 402 Application note | √ |
All hardware specific parts are decoupled from the CANopen protocol stack through a defined driver interface. This provides easy adaptation to different hardware platforms. The user application communicates with the CANopen Library through function calls and call-back functions.
Configuration and scaling of the CANopen Library is done with the help of the CANopen Design Tool,
which is delivered as CANopen Design Tool Light version. With it the CANopen Library can be tailored to an optimum to the available resources of the application. Besides the creation of the object directory all settings for the hardware can be carried out with it.
The CANopen Library consists of a hardware independent and a hardware dependent part that communicate with message queues. The hardware dependent part consists of controlling software for the CAN controller and timer functions. A detailed description can be found in the CANopen Driver Package.
The application
communicates only with the hardware independent part of the
CANopen Library. That way it is possible to exchange
drivers without any influence on the functionality of the
application. The initialization of CANopen services is done
with function calls within the application. During the
execution of the application the CANopen Library
executes all necessary communication tasks autonomously and
informs the application about CANopen messages with the help
of callback functions.
Communication requests from
other devices as well as necessary periodical tasks and time
out monitoring is handled within the CANopen Library.
All requests are proved for correctness (access rights, data
types etc.). The application is notified after completion of
the communication and occurrence of failures, respectively,
through service oriented callback functions. In these
callback functions appropriate actions can be carried out
from the application.
The object directory is designed to contain references to the variables in the user application. Consequently it is possible to take over variables from an existing software without any changes in the object dictionary.
The high degree of scalability of the CANopen Library is of particular importance for devices with limited resources. On one hand, this is achieved by the modularity in individual service groups, like sdo.c, pdo.c, ...sync.c, and on the other hand, through the use of compiler directives in the respective modules.
Thus, the code size is proportional to the utilized CANopen services.
Furthermore, variants of the CANopen Library for the support of multiple CAN lines (max.255) are available. Therefore it is possible to serve several independent CAN networks on devices without an operating system or with an operating system. The usage of an operating system requires it to provide means of resource protection mechanisms. Each line holds its own object directory and can be used as master and slave, respectively, independent of the other lines. Owing to the separation of the protocol stack and the hardware drivers, the individual lines can also be operated with different CAN controllers.
Delivery of the CANopen Library comprises different example programs that describe the usage of the various CANopen services. All examples contain a complete implementation of a CANopen device including the object directory as well as application code. These are ready to be compiled and run.
Among the detailed documented source code there is the reference manual and an a printed user manual, numbering 200 pages, as documentation of the CANopen Library available.
The CANopen Library is constantly improved and adopted to customer requirements. In order to keep up with the latest version of the CANopen Library port provides its customers an update service.
The support engineers of port are ready to answer all questions by email, phone or fax regarding the initial operation of the CANopen Library or further questions to the topic CANopen. This service is exempt from charges up to 6 months for requests by email and fax and up to 6 months for requests by phone.
For development, test and initial operation of CANopen devices port provides a comprehensive tool chain. The creation of the object directory is simplified with the CAN- open Design Tool (CANopen Design Tool Light version belongs to the scope of delivery).
The graphical CANopen Design Tool is available for the creation of the object directory, the electronic data sheet (EDS file) and for the documentation of the device in HTML or text format.
The CANopen Device Monitor can be utilized for commissioning, but also for the implementation and test phase. As a fully implemented CANopen master the CANopen Device Monitor with a graphical user interface assures access to all services in the network and also allows analysis of the bus traffic.
For the development of CAN application monitoring and analyzing the CAN bus traffic is essential. The service oriented display of CANopen messages of the CAN-REport allows easy and quick interpretation of CANopen messages.
Besides the
communication objects of the CiA 301 several
application objects in different device profiles are also
specified in CANopen. These definitions guarantee a defined
behavior of the corresponding device class and enable the
interchangeability of CANopen devices.
For these
different device profiles port provides
extension modules as an add-on to the CANopen
Library. These modules allow the customization of an
application based on the CANopen standards.
All
modules are available in ANSI-C source code and can be used
with all versions of the CANopen Library.
Please have a look at the information of the data sheet CAN- open-Library Extension modules.
We support all CAN implementations that can be found in ATMEL controllers. Fortunately ATMEL is always using variants of its CANary CAN module.
- T89C51CC01
8-bit micro-controller with CAN controller and 32-Kbyte Flash, 1k RAM, 2 kbyte EEPROM. - AT89C51CC03
8-bit micro-controller with CAN controller and 64-Kbyte Flash. 2-Kbyte RAM, 2-Kbyte EEPROM, SPI. Power Fail Detect (no need for external brown- out). Pinout compatible with T89C51CC01. - AT90CAN128
8-bit AVR Microcontroller with 128K Bytes of ISP Flash and CAN Controller - AT91SAM7A, Atmel’s ARM controller with integrated CAN. At the low end, Atmel’s AT91SAM7A series of Flash microcontrollers based on the ARM7TDMI provide one or 4 CAN channels with up to 16K SRAM.
- AT91SAM7X, Atmel’s ARM controller with integrated CAN and Ethernet.
- CAN Controller 2.0A & 2.0B
- 15 Full Message Objects with separate Identifier Tags and Masks
- Transmit, Receive, Automatic Reply and Frame Buffer Receive Modes
- 1Mbit/s Maximum Transfer Rate at 8 MHz
- Time stamping, TTC & Listening Mode (Spying or Autobaud)
The first CANopen
implementation was done using the
ASTK500/ASTK501
and the WinAVR
gcc-avr based compiler.
WinAVR
(pronounced "whenever") is a suite of open source
software development tools for the Atmel AVR series of RISC
microprocessors for the Windows platform. It includes the
GCC compiler for C and C++.
Download the AT90CAN128 manual. CAN is described on page 229 and following.
All price sensitive applications with the need of high processing power can now use the new ARM based controllers:
- The AT91SAM7A1 features a 36 MIPS ARM7TDMI processor with 4K bytes of SRAM, fully programmable External Bus Interface (EBI) and a rich peripheral set including one CAN controller (2.0A and 2.0B Full CAN) and four-channel 16-bit Pulse Width Modulation.
- The AT91SAM7A2 features a 27 MIPS ARM7TDMI processor with 16K bytes of SRAM, fully programmable External Bus Interface (EBI) and a rich peripheral set including four CAN controllers (2.0A and 2.0B Full CAN) and four-channel 16-bit Pulse Width Modulation.
- AT91SAM7A3 features a 54 MIPS ARM7TDMI processor with 256K bytes of high-speed Flash, 32K bytes of SRAM and a rich peripheral set including two CAN controllers, a USB 2.0 device, one 8-channel 20-bit Pulse Width Modulation, two 8-channel 10-bit
- AT91SAM7X is a family of low pincount Flash microcontrollers based on the 32-bit ARM RISC processor. A large set of peripherals, including a USB 2.0 device, a 10/100 Ethernet MAC, a CAN controller and a complete set of system functions are minimizing the number of external components.
Use the following order codes to specify your used CAN implementation and processor.
| 0565/10 | Driver Package ATMEL AT89C51CC01/CC03 (Keil-C) | ||
| 0565/35 | Driver Package ATMEL AT90CAN128 (gcc-avr) | ||
| 0565/40 | Driver Package ATMEL AT91SAM7A2 (Keil-C) 36 MIPS ARM7TDMI | ||
| 0565/47 | Driver Package ATMEL AT91SAM7A3/SAM7X256 (IAR) | ||
| 0566/09 | Driver Package CANary | ||
| 0566/18 | Driver Package AT91SAM7A internal |
The CANopen Library runs on targets with and without operating systems. It supports many of the available CAN controllers and many microcontrollers/processors. For detailed information see data sheet CANopen Driver Package.
For systems based on Windows™ the CANopen Library is also available a Dynamic Link Library (DLL). This DLL is available for special hardware boards and contains all services of the Master/Slave standard edition of the library. It can be used to create master or slave applications.
Furthermore CANopen-Starter Kits and a free CANopen Evaluation software on CD are available on request.
- CANopen library with separate driver interface
- CPU/CAN driver
- numerous, immediately compilable examples
- CANopen Design Tool Light
- detailed user manual
- reference manual containing descriptions of all functions including parameters and return values
- 6 months support by E-Mail free of charge
- 6 months update service free of charge
CANopen Design Tool Light
- generates an object dictionary and an initialization function in C-code, an Electronic Data Sheet and the documentation are produced automatically
For the CANopen
Library a one-off license fee is charged in form of the
purchase price. Further license fees do not arise from the
deployment of the software within the same company (no
runtime licenses).
It is not allowed to hand over the
software and the implementation, respectively, towards a
third party.
Maintenance
Agreement
All changes of current standards as well as
extensions through new developed standards are constantly
incorporated into the CANopen Library. In order to
take profit of the changes port offers all its
customers a maintenance agreement with the following
conditions:
- updates free of charge for the contracted period
- free of charge support for the CANopen Library and topics of CANopen
Support for initial
operation
In order to provide a quick and effective
access to the development of CANopen devices we recommend to
do the initial operation of the CANopen device together on
the target platform. Customer experiences of his/her
hardware and the used compiler and the experience of our
engineers with CANopen and the CANopen Library can
complement each other. This leads to reduced development
times and a CANopen conform device.
Conformance Test
In preparation of the charged Conformance test of the
CiA we provide you our service, knowledge and equipment.
With the preparation and execution of preliminary tests
possible problems can be detected and removed.
System analysis,
consulting and support
Take profit of our Know How
during planning and development of your CANopen devices and
networks. An ideal design requires knowledge about the used
protocols and the system environment. Our competent
engineers create together with you a cost-efficient solution
that fits your needs to an optimum.
Software development services for CAN, CANopen and DeviceNet
Training
To
simplify the first steps with a new technology
port provides one-day and several-days
trainings for the topics of CANopen and its services as well
as for the CAN- open Library and its tools. These
trainings can be given at port or at your
companies rooms and are exclusively carried out for your
workers.
CANopen User Manual
You want to get to know about the advantages of our
CANopen Library? Then our user manual is the best
starting point to get an overview about the functionality
and deployment possibilities of the CANopen Library.
| 0564/01 | CANopen-SRCLIB Slave Small |
| Single Line | |
| 0564/12 | CANopen-SRCLIB Slave |
| Single Line | |
| 0564/10 | CANopen-SRCLIB Master/Slave |
| Single Line | |
| 0564/15 | CANopen-SRCLIB Slave |
| Multi Line | |
| 0564/13 | CANopen-SRCLIB Master/Slave |
| Multi Line | |
| 0910/xx | CANopen-DLL Master/Slave |
| 0564/90 | CANopen-SRCLIB User Manual |
| (Paperback) | |
| 0571/10 | CANopen-SRCLIB |
| Software Maintenance Agreement | |
| 0564/39 | CANopen Evaluation-Software |
| 0569/10 | CANopen Training Course |
| 0570/10 | CANopen Integration Support |
| 0572/01 | CANopen Starter Kit for LINUX |
Besides the standardization of communication objects CANopen specifies application objects used in various device profiles. These device profiles guarantee a defined device behavior and provide thereby interchangeability of CANopen devices.
For employment of these profiles port provides extension modules for its CANopen Library. These modules make it possible to use the desired device profiles easily.
Currently port supports the following device profiles:
| • CiA 301 | SDO Block Transfer | |
| • CiA 301A | Multiplexed PDO’s | |
| • CiA 302 | Flying Master | |
| • CiA 302 | CANopen Redundancy Support | |
| • CiA 302 | SDO Manager/
SDO Requesting Devices | |
| • CiA 303-3 | LED Modul CANopen Indicator | |
| • CiA 304 | Safety-Relevant Communication | |
| • CiA 305 | LSS Layer Setting Services | |
| • CiA 401 | Generic I/O Modules | |
| • CiA 402 | Drives Support |
All modules are available in ANSI-C source code and can be used with all versions of the CANopen Library.
CiA 301 SDO Block Transfer
SDO transfers are
based on the client-server model with a handshake after each
transfer. For a larger block of data this will take a large
amount of time. Therefore a new SDO mode has been defined in
CiA 301 V4.x. It is called SDO block transfer.
Using the block transfer a sequence of blocks can be
transmitted without a large overhead. Each block is a
sequence of up to 127 segments (e.g. CAN telegrams)
containing only a sequence number and the data.
CiA 301A Multiplexed PDO’s
If the application
has a lot of data with the same properties a special PDO
type can be used. It is called a Multiplexed PDO (MPDO).
MPDOs transmit with every telegram the index and the
sub-index of the given data. Therefore the maximum data
length can be only 4 bytes. The transmitted index and
sub-index can be the index and the sub-index of the
producers object dictionary (MPDO Source Addressing Mode) or
the index and the sub-index of the consumers object
dictionary (MPDO Destination Addressing Mode).
CiA 302 Flying Master
The package CiA 302 Flying Master is an extension to the CANopen Library library of port and provides functions for implementing the flying master functionality for CANopen devices. Flying master means that a second device in a network can take over the master role when the master dropped out.
The provided functions fulfill all demands of the standard:
- determination of master device in a network
- detection of the active master
- priority driven master negotiation
- check for multiple master
The application is
informed about changes of the master state with indication
functions.
CiA 302 Redundancy Communication
For employment of
communication systems in maritime applications a redundant
bus system is required. Because only the communication has
to be redundant all services provided by CANopen can be used
by this package. With function calls the redundant
communication is handled automatically by the library.
Information about other events in the different bus systems
like drop out of one bus line, restoration of a bus line,
missing communication and others are provided to the
application with indication functions. Redundancy needs at
least two CAN controllers. port offers
implementations for stand alone CAN controllers as well as
with microcontrollers with more than one CAN integrated.
CiA 302 SDO Manager/SDO Requesting Devices
SDO connections exist exclusively between Client and Server. For the operation of configuration and analysis software as well as HMI which are only temporarily present in a network static SDO connections are not possible. For these cases the use of dynamic SDO connections is foreseen. With the extension module CiA 302 SDO Manager/SDO Requesting Devices the CANopen Library of port can be expanded to use this functionality.
The module contains functions for implementing either an SDO manager or an SDO requesting device. All functions described in the standard are available:
- manage dynamic SDO connections (request, release, configure, monitor)
- manage the COB IDs of SDO
- manage the SDO connection table
Furthermore functions to request or release SDO connections are enclosed:
- register as an SDO requesting device
- request/release SDO connections
- request all default connections
CiA 303-3 LED Module
For a consistent state or error indication respective error diagnosis of CANopen devices the module LED is available. It is included in the default delivery of the CANopen Library.
According to the specification of CiA 303-3 a NMT-LED and an Error-LED can be used as two single colored LED or as one bicolored LED. The state machine for controlling the LED is realized within the module. The desired configuration can set with the configuration tool.
On state change of either NMT or error state the application is informed by an indication function which will then control the LED, i.e. switch on or off the appropriate LED.
The LED module is
alltimes delivered by the library.
CiA 304 Safety-Relevant Communication
In order to transmit safety relevant data in a CAN network further measures have to be taken. This is done with this extension package. Communication takes place with so called SRDO i.e. Safety Relevant Data Object. These objects have communication and mapping parameter like PDO. The further measures consist of:
- sending data as plain and inverted data with different CAN identifier
- monitoring of sending data cyclically and in correct order
- protecting communication and mapping parameter with a checksum
- additional activation flag in the object directory
All monitoring functions can be realized with functions of the CANopen Library, but considering safety aspects monitoring functions should be implemented by the application developer.
Consistency of the data in the object directory is achieved through further safety measures.
- modification of communication and mapping parameter is only allowed in the state PRE-OPERATIONAL
- on modification all data lose their validity
- mapping data is also stored inverted
- a
checksum calculated over all data of an SRDO
is checked when changing into state
OPERATIONAL
With this all
planned safety measures of the standard are realizable.
CiA 305 Layer Setting Services
The extension package LSS (Layer Setting Services) for the CANopen Library contains all functions to operate CANopen devices as LSS Master or LSS Slaves. With it unconfigured devices in a network can be identified by their unique manufacturer, product, serial and revision number and configured. After identification bit rate and node id can be configured for each device.
Configuration with LSS can only be implemented on a CANopen
master. With function calls existing slaves can be
identified or addressed. In indication functions the
responses of slave devices can be processed by the
master.
Responses of the LSS slaves to LSS requests of the master are generated automatically by the CANopen Library. Only when new parameters like bit rate or node id are set the application will be informed with indication functions.
Delivery comprises source code, documentation and example code to get started quickly.
CiA 401 generic I/O modules
Delivery comprises source code and documentation.
CiA 402 Drives Support
Drives Support is available from port in different ways. First of all using the CANopen Design Tool and its CiA 402 profile data base. Second, from a lot of implementations we did, we have some collected and assembled supporting functions in C combined in a CiA 402 framework. And third, our experience. Implementing drives and the CiA 402 profile is one of the most complicated programming tasks.
For the test of an drives implementation according to CiA 402 the CANopen Device Monitor with its drive specific plug-in is suggested. Look at the drive state machine or the different movement modes in a graphical way.
| 0564/50 | CiA 401 Source Code Generic I/O Modules |
| 0564/51 | CiA 401 Source Code and Profile Database for Generic I/O Modules |
| 0564/52 | CiA 302 Source Code Flying Master |
| 0564/54 | CiA 305 source code Layer Setting Services |
| 0564/55 | CiA 304 Source Code Safety-Relevant Communication |
| 0564/57 | CiA 307 Source Code CANopen Redundancy |
| 0564/58 | CiA 304 Source Code and Profile Database for Safety-Relevant Communication |
| 0564/60 | CiA 302 Source Code dyn. SDO Manager/ SDO Requesting Devices |
| 0564/62 | CiA 301A Source Code Multiplexed PDO’s |
| 0564/63 | CiA 301 Source Code SDO Block Transfer |
| 0564/66 | CiA 402 Source Code (Template for Drives functionality) |
| 0564/67 | CiA 402 Source Code (Template for Drives functionality) and Profile Database |