Embedded modules & gateways for CANopen networks

  • Modular Gateway

    Modular Gateway

    Gateway connecting CANopen to other network protocols

CANopen is a communication protocol based on CAN and used in automation engineering for networking of complex device structures. CANopen is a further development of CAN, introduced by BOSCH for reduction of cables in automobile manufacture. As CANopen was initiated by the German small and medium-sized companies and was supported by Bosch, CANopen initially spread from Germany to Europe. By now, CANopen has also spread to North America and Asia. Since 1995, CANopen is maintained by the user and manufacturer organization CAN in Automation (CIA) and has been standardized as the European standard EN 50325-4 since 2002.

For this, the KUNBUS GmbH offers products in various forms and different interface variants.

Within a product family, the different fieldbus protocols can be exchanged. A uniform pin-out enables use of the IC modules as option cards.


CANopen Basics:

CANopen is based on CAN (Controller Area Network) and represents a communication protocol mainly used in automation technology. With this, CANopen combines several basic services, which are also called service primitives.

These are as follows:

  • IIndication (the application is notified that the message/result is present)
  • Response (the application answers to indication)
  • Confirmation (when a CANopen service is being performed, a confirmation is sent to the application)

CANopen uses the following communication objects:

  • (SDO) Service Data Object for object dictionary entry parameterization
  • (PDO) Process Data Object for real-time data transport
  • (NMT) Network management objects for state machine control and node monitoring
  • (SYNC) Synchronization object
  • (EMCY) Time stamp and error messages

The CANopen Object Dictionary

All user and communication objects are registered in the CANopen object dictionary. The CANopen object dictionary is also called the link that connects the application and the communication unit. The individual entries are characterized by a 16-bit index and each represent one object. An index can contain max. 256 sub-indices, where a total of 65536 x 254 elements can be recognized. Free use of the sub-indices 0 and 255 is not possible. As mentioned above, the CANopen object dictionary forms an interface to the outside, and it is defined clearly as a device profile as well as a communication object with the aid of the index. Each communication object of CANopen furthermore has a unique communication object identifier = COB-ID in the network. The first two bits of the 32-bit COB-ID are provided with an object-specific meaning. With this, the bits 29 to 11 in an 11-bit CAN network are given the value 0, while the bits 10 to 0 are equal to the CAN identifier. The service data objects provide the corresponding service so that access to the object library is possible within CANopen. With this, at least one SDO server must be available for each CANopen device. This server takes over the job of accepting and processing SDO requests. Here, messages use either the node number + 1536 or accordingly the CAN identifier per default setting as the COB-ID. The node number + 1408 is then used for the answer. IDs with a low priority are thus used to transfer entries in the object library. A 4-byte protocol is required for the SDO transfer, so that index, sub-index, and transmission direction can be coded. As a CANopen data field has only 8 bytes available, only 4 bytes are available to the data contents for free use. Accordingly, data quantities larger than 4 bytes and to be communicated by SDO transfer must fall back on another two protocols.

The identifier with higher priority in CANopen

In order to ensure that process data can be transported quickly in the CANopen network, the default settings of the identifiers with COB-ID are in the range from 385 to 1407. Because of the higher priority and the fact that only payload data is included, a total of 8 bytes is available here. PDO mapping entries determine the contents of the payload data, which are objects in the object library. In connection with the PDO, it is also possible to transfer objects with several values, where only parts of the data can then be used by the receiver. The transfer of PDOs takes place on a cyclical or a synchronized level, where the reception of PDOs causes mapping entries to be written into other objects in the object library.

CANopen – Independence from Manufacturers

The unified device profiles for the CANopen network also enable applications independent of manufacturers. For this purpose, device profiles were defined, for example purpose 401 = input/output module. The object library assures an exact definition of functionality and structure for the respective devices by means of the device profiles. The CANopen installation: The wiring of the CANopen network at the beginning as well as at the end takes place in bus topology with resistors of 120 Ohm. With this, care must be taken to avoid stub lines. While data transfer via the CAN-H and CAN-L signals takes place with GND as data reference potential, a twisted-pair cable (impedance: 120 Ohm, resistance 70 mOhm/m) is routed out. Optionally, use of a 24 V power supply is possible. As a rule, a 9-pin D-sub plug is used to connect the individual participants to the CANopen network. The adjustable transfer speed is between 10 kbps and 1 Mbps, where max. 127 participants can be connected to the CANopen network.