CANopen provides distributed control functionality
The CANopen application layer provides several protocols. The only mono-master protocol is the network management (NMT) protocol. There is usually just one NMT master device that sends the NMT message to control the other CANopen devices. To avoid a single point of failure, CANopen provides an optional NMT "Flying" master functionality. This means that there are additional CANopen devices in the network that provide NMT master functionality, but this function is not yet activated. If the active NMT master device loses connection to the network, the remaining devices with "sleeping" NMT master functions start to negotiate as to which one will act as the NMT master. Each NMT master capable device has a unique priority, assigned by the system designer. If a temporarily disconnected NMT master-capable device is connected it again, it requests the priority of the active NMT master and possibly starts the above-mentioned negotiation process. The NMT "Flying" master process comprises four protocols.
The Heartbeat is a producer/consumer service. This means any node produces its Heartbeat to indicate that it is still in the network. All other CANopen device may consume the Heartbeat of others. The system designer can configure this for each node differently. The EMCY (emergency) message is also a producer/consumer service. The system designer can configure the EMCY reception by means of standardized parameters in the CANopen object dictionary.
Process data objects (PDOs) also follow the producer/consumer model, making it a true multi-master system. They are sent in broadcast to all connected nodes, and depending on the implemented hard- and software message filtering, they are processed or ignored. One of the misunderstandings comes from the pre-defined CAN-ID connection set. The basic CANopen document (CiA 301) specifies a default assignment of CAN-IDs for the different communication protocols. There are just four pre-defined CAN-IDs for PDOs to be transmitted for each node. Additionally, there are four pre-defined CAN-IDs for PDOs to be received. This means that there is a pre-configured set of PDOs normally consumed and produced by a host controller. But the system designer can configure the CANopen devices in a way that the cross-communicate PDOs, as well as multi-cast them, making it is possible to configure a full-meshed PDO communication.
Another misunderstanding is regarding the default service data objects (SDO) communication. SDOs are used to write or to read the parameters in the object dictionary. This is a client/server communication. The client always has the initiative, and the server responds to the write or read request with a confirmation. In case of reading, the SDO server provides the requested data in the confirmation. The above-mentioned pre-defined CAN-ID connection set features just the Default-SDO communication, meaning each CANopen node has just one pre-defined CAN-ID for receiving the request from the SDO client and another one to transmit the confirmation to the SDO client. Normally, the host controller owns all SDO clients for all the Default-SDOs of the other CANopen devices, but it is possible to assign unused CAN-IDs to not pre-defined SDO-channels. At the end, each CANopen device can be the SDO client for each other and vice versa. This would be a fully meshed SDO network.
CANopen can be used to design a network with multiple host controllers. In this case, the host controllers can share the network to communicate PDOs and SDOs. Additionally, they can share the connected other CANopen devices. For example, an I/O module can communicate with one PDO its inputs to one host controller and with another PDO other inputs to another host controller. The I/O module can even be host controller by itself.
One CANopen device can implement multiple SDO servers, so that different host controllers can configure it. Such real distributed control systems may have a single-point of failure if no NMT "Flying" master functionality is implemented. The subsea controllers make use of redundant NMT masters, and some other mission-critical applications implement the NMT "Flying" master protocols. In the elevator control business, multiple host controllers are used, sharing the network and communicating via the very same bus-lines with the assigned CANopen devices. Multiple host controllers are also used in CANopen-based rail vehicle applications. In industrial machine control systems, most of the applications implement just one "big" host controller collecting all input data and transmitting all commands to the actuators. In mobile machine control systems, sometimes multiple host controllers are used. The trend of modular machine design will also be adapted in industrial and other machinery, such as laboratory automation and medical apparatuses. CANopen provides all necessary features for such distributed control architectures.
– Holger Zeltwanger is managing director, CAN in Automation, a CFE Media content partner. Edited by Anisa Samarxhiu, digital project manager, firstname.lastname@example.org.
- CANopen can be used to design a network with multiple host controllers. In this case, the host controllers can share the network to communicate PDOs and SDOs.
- The trend of modular machine design will also be adapted in industrial and other machinery, such as laboratory automation and medical apparatuses. CANopen provides all necessary features for such distributed control architectures.
- The basic CANopen document (CiA 301) specifies a default assignment of CAN-IDs for the different communication protocols. There are just four pre-defined CAN-IDs for PDOs to be transmitted for each node.
How would you use the multi-master functionality of CANopen-based control systems?
See related articles below as well as other CAN in Automation articles.