Optimizing communications for embedded machine control systems

Opposite to factory automation, embedded machine control systems need to be optimized to design better products than those of competitors. This requires configuring the communication, in particular the scheduling and content of control and status messages. The process data object (PDO) protocol transmits, in real-time, control and status information as well as measured values.

By CAN in Automation June 3, 2014

CANopen has been designed for embedded machine control systems. Opposite to factory automation, embedded machine control systems need to be optimized to design better products than those of competitors. This requires configuring the communication, in particular the scheduling and content of control and status messages.

CANopen uses the process data object (PDO) protocol to transmit, in real-time, control and status information as well as measured values. PDOs are mapped to a single CAN data frame, which is normally send asynchronously. Asynchronous transmission includes trigger by means of a change-or-state and by means of elapsing of the event timer. Many system designers use a periodical transmission of PDOs, which cause high busloads. Most of the standardized CANopen profiles pre-define a change-of-state scheduling. In the best case, this causes just one transmission when entering the operation state. Depending on the change-of-state configuration any change triggers a PDO or the corresponding message is only transmitted when a specific threshold is reached (above or below). Of course, if the value changes frequently this can cause a lot of traffic. To reduce the busload, the system designer can configure the inhibit timer, which forbids to send the message again for a specified time. Of course, this doesn’t effect the automatic transmission of faulty messages.

In some applications, synchronization between different CANopen devices is required. For example, several sensors need to measure at the very same moment the sensor values or several actuators need to start operation simultaneously. For those applications, CANopen uses the SYNC message, which triggers the capturing of current values and enables already received commands. It is also possible to configure a PDO in the transmitting device as synchronous and in the receiving device as asynchronous meaning the process data is immediately processed. Or vice versa, the Transmit-PDO (TPDO) is sent asynchronously (change-of-state) and the corresponding Receive-PDO (RPDO) is configured as synchronous and performs the command when the next SYNC is received.

Synchronous PDOs also can cause high busloads. In order to reduce it, CANopen allows to configure them in a way that the TPDO serves only each second, third, etc. SYNC. The "slowest" synchronous TPDO serves every 240th SYNC message. Another option to reduce busload is to send synchronous TPDOs acyclic.

Besides the scheduling of messages, CANopen allows to optimize the PDO communication by means of the assigned priority. In CANopen, each device may support up to four TPDOs and up to four RPDOs with pre-defined CAN identifiers, which determines the bus access priority. This means each device may have one high-prior, one middle-prior, one lower middle-prior, and one low-prior PDO. The system designer can be lazy, not reconfiguring the PDO priority. But it is also possible to reassign the pre-defined priorities to optimize the time delay for the more important and critical data. In some applications, a dedicated device may require more than one high-prior PDO.

To tune the PDO communication, the system designer can also assemble those process data into one PDO, which have the same priority and scheduling requirements. This is known as PDO mapping: you pack together what fit together. In classical CAN this is limited to 8 byte. The upcoming CAN FD (flexible data-rate) protocol, so-to-say the next generation CAN protocol, supports data length up to 64 byte. Of course, it transmits the data with a higher speed. It is intended to use for embedded machine control networks an arbitration bit-rate of 500 kbit/s, 250 kbit/s, and 125 kbit/s depending on the bus length (125 m, 250 m respectively 500 m). The data-phase speed can be increased by the factor two, four, or even eight. Considering a data-phase bit-rate of 4 Mbit/s and an arbitration bit-rate of 500 kbit/s seems to be realistic. Running a bit-rate of 1 Mbit/s is also possible, but an increase in the data-phase to 8 Mbit/s is a challenge for the physical layer design, when the same robustness and reliability as in classical CAN is required. The lower the speed the less are the challenges. By the way, this is true also for other communication technologies including Ethernet-based solutions.

In both protocol variants, classical CAN and CAN FD, the mapping of process data is configures by means of tables providing pointer to the process data to be mapped into a dedicated PDO. The mapping lists of a length of 64 entries meaning you can assemble up to 64 process data. In case of the classical CAN protocol, you can map bit-wise data. Using the CAN FD protocol, you are limited to an 8-byte granularity when using the maximum payload of 64 byte.

To summarize, CANopen is one of the most flexible network technologies in respect to optimize process data communication. On the other hand, the PDO optimization requires configuration. Software tools support this. Configuring CANopen networks by hand it is not state-of-the-art.

– Edited by Jessica DuBois-Maahs, associate content manager, CFE Media, jdmaahs@cfemedia.com.