CAN Newsletter magazine
The CANopen application layer was developed under the umbrella of a European research project. In the last three decades, it has penetrated many application fields. CAN in Automation (CiA) has released more than 20 000 pages of CANopen profile specifications.
The predecessor of CANopen, was the CAN Application Layer (CAL) specified by CiA members in 1992. Because the CAL specifications were very academic based on the OSI reference model, the ASPIC (Automation and Control System for Production Units and using an Installation Bus Concept) European research project was launched. Bosch led it and mayor contribution came from the University Newcastle (UK). The project participants introduced dedicated application layer protocols and a communication profile. This included the CANopen dictionary with a 16-bit index and an 8-bit sub-index addressing method for parameters. The communication parameters were assigned to the index range from 1000h to 1FFFh. In the range 6000h to 9FFFh, process data, application configuration, and diagnostic information of standardized profiles are available. Proprietary application parameters use the index range from 2000h to 5FFFh. The research results, about 30 pages, were handed over to CiA for further development and maintenance.
End of 1994, CiA released the first version of the CANopen application layer and communication profile, which was updated just two months later. Version 2.0 was the base for the first CANopen demonstrator exhibited on the Hanover Fair CiA booth in 1995. In the beginning, the name “CANopen” and the document number “CiA 301” were not used. But from version 3.0, this CAN-based application layer and communication profile was published in the CiA 301 document. This version was implemented in the first commercially available CANopen devices. In the beginning, IEC 61131-compliant programmable logic controllers (PLC) were rare.
CANopen host controllers were mainly embedded control devices programmable in computer languages such as C and C++. But actuator and sensor manufacturers provided increasingly CANopen interfaces for their products. Embedded host controllers not fully compliant with CiA 301 were able to control and manage these CANopen products. Many of them did not provide an object dictionary. The disadvantage: They could not be diagnosed via the CAN network. Of course, there were some misunderstandings of the CiA 301 specification. Many engineers thought and some still do it today that the pre-defined connection set of CAN identifiers comprising a 4-bit function code and a 7-bit node-ID have to be used.
The truth is that only the Default SDO client message, the Heartbeat messages, and the NMT message have fixed function codes. All other CANopen messages can be configured with all not restricted 11-bit CAN identifier values. Details are given in CiA 301. Another misinterpretation is that the SYNC and the TIME messages need to be send by the CANopen host controller. Correct is that any CANopen device can do it. The system designer has to take care that there is a consistent assignment of the producing and consuming CANopen devices.
There are also misunderstandings caused by not often implemented features. A feature could be specified, but nobody has implemented it. This does not mean that this feature is not provided by CANopen. Some people think that CANopen is complex. But it is not. It is more complex to specify all the CANopen functions by yourself. CANopen specifications are like menus: You need to order and eat only what you like. You don’t have to take all offered meals.
From CANopen version 4.0 onwards, four PDOs to be transmitted and four PDOs to be received can be assigned with a pre-defined CAN identifier. This version also introduced the Boot-up message using the same fixed (not configurable) CAN-ID as the Heartbeat message. In version 3.0, some device manufacturers misused the EMCY message as a boot-up indication. CiA does not recommend to use CAN remote frames at all. Therefore, NMT node-guarding and remotely requested PDOs are no longer state of the art. It is also not recommended to change the bit-timing parameters and the node-ID number by means of SDO services in the CANopen object dictionary, because this could lead to severe network problems. If you like to configure them via the CANopen interface, layer setting services (LSS) should be used as specified in CiA 305.
The first CANopen device profile released specified the process data and configuration parameters for input/output (I/O) modules. This specification is known as CiA 401 and covers digital and analog I/Os. Besides this very generic profile, CiA members developed the CiA 402 profile for (electrical) drives and motion controllers. This was and is one of the most successful CiA profile specifications. In the meantime, it is internationally standardized in the IEC 61800-7 series. It has been adapted also by other communication technologies, especially Ethercat. There are also profiles for encoders (CiA 406) and inclinometers (CiA 410), which are used in very different applications fields.
They range from textile machines via pitch control in wind-power systems and medical scanner devices to cranes and construction machines – just to name some of the important ones (see insert “CANopen application stories”). CiA has specified also application-oriented profiles. The CiA 417 series, for example, specifies elevator control systems. The CiA 422 series internationally standardized in EN 16815 describes the CANopen interfaces for refuse collecting vehicle equipment. There are still some unused treasures in the CiA profile portfolio. In total, the CiA profile specifications comprise more than 20 000 pages. There are also profiles developed jointly or even outside of the CiA community. The CiA 420 series of profiles for extruder downstream devices has been published with nonprofit Euromap association for plastics and rubber machinery manufacturers. DIN has released the DIN 14700 series of CANopen-connectable fire-fighting equipment. This German standard is under review and will be published in English language.
News and reports