Datasheet as PDF

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.

Philips is one of the most active and most popular semiconductor manufacturers world wide. Philips even plays an important role and has a lot of products using CAN. Philips Medical Systems is one of the parents of the todays CANopen protocol.

Philips manufacturers one of the best stand alone type CAN controllers, the SJA1000. It is the successor of the PCA82C200 CAN controller (BasicCAN). Additionally, a new mode of operation was implemented (PeliCAN) which supports the CAN 2.0B protocol specification with several new features.

The SJA1000 is also supported by the can4linux LINUX device driver.

port supports the following Philips components:

• SJA 1000 Stand alone CAN controller (or PCA82C200 predecessor)
• Philips ARM Series LPC2000

Use the following order codes to specify your used CAN implementation and processor.

0565/39		Driver Package Philips LPC2194
0566/01		Driver Package CAN Philips SJA1000
0566/19		Driver Package CAN Philips LPC21xx/LPC22xx
0567/19		Driver Package CPU Philips LPC21xx/LPC22xx

Products of Philips now ranging from the very famous stand-alone CAN SJA1000 to different types of micros with integrated CAN.

• 8xC592, 8-bit CAN microcontroller
• 8xCE598, 8-bit CAN microcontroller
• 8xC591, 8-bit CAN 2.0B microcontroller
• XA-C3, 16-bit CAN 2.0B microcontroller
• 32-bit ARM with CAN LPC2119/2129/2292/2294

Because the CAN implementation used inside is almost the SJA1000 model, port’s CANopen library can be used for all of them.

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

Datasheet as PDF

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

The application is informed about events by means of indication functions.

Furthermore functions to request or release SDO connections are enclosed:

• register as an SDO requesting device
• request/release SDO connections
• request all default connections

The package contains source code, documentation and example programs for getting into it quickly.

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

The device profile for Generic I/O-Module is an extension to the CANopen Library of port and provides functions for realizing I/O devices that conform to the device profile CiA 401. The implemented functions realize the functionality as specified in the standard, i.e.   logic operations, polarity switching, filter mechanisms, limit monitoring and others. The developer has to provide functions to access the hardware, ie. reading inputs, writing outputs.

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