Experience over the years has uncovered some oddities in the CAN protocol - which are naturally not covered by any official document - and one of them has lead to the call to avoid CAN remote frames. In August of 2005 CAN-in-Automation (CiA) released (but not promoted) their application note 802 - "CAN remote frame - Avoiding of usage". The document can be requested through the 'Contac Us' section on their web site (http://www.can-cia.org).
As a reminder, data frame and remote frame are very similar. Basically, the remote frame is a data frame without the data field (which would be located between the Control Field and the CRC Filed). Data frame and remote frame are distinguished by the RTR bit in the arbitration field (Data frame: RTR=0, Remote Frame: RTR=1).
One source of the problem with the remote frame is based in the way the Control Field, especially the data length code, is being transmitted:
For further detailed information on the Control Field and the Data Length Code, please refer also to the next chapter 4.5 Message Frame Format.
The actual problem lies in protocol-incompatibilities between CAN controllers of different manufacturers and how they handle the Remote Frame, which consequently will result in bus collisions.[1]
A bus collision may occur under the following conditions:
- Two or more CAN nodes in a network request the same message at the same time or remote frame and requested data frame access the bus at the same time (latter condition is not mentioned in the CiA application note).
- The data length codes differ between the nodes.
The remote frame and the requested data frame use the same message identifier. Both frames are distinguished by the RTR (Remote Transmission Request) bit, which is part of the arbitration field. In case a data frame and a remote frame using the same message ID try to access the bus simultaneously, the data frame will gain the bus access over the remote frame, since it uses a dominant RTR bit.
Remote frames can only be transmitted with a data length code (DLC) identical to the DLC of the corresponding data frame. Simultaneous transmission of remote frames with different DLC's will lead to irresolvable collisions, meaning the CAN bit monitoring feature will detect an error. That also means in all consequence that the requesting node must know the correct DLC.
What happens next is the same as when two frames with the same message ID try to access the bus. This result of this scenario has so far not been documented in any official literature. The official statement is that such scenarios are not allowed and will lead to unpredictable results. However, as CiA application note 802 explains, there are quite some discrepancies between the numerous CAN controllers available in the market and how they handle remote frames. It appears that collisions can occur with such probability that the use of remote frames is not recommended at all.
CAN Remote Frames under CANopen
The use of remote frames under CANopen is restricted per design, however, the problem remains. The wording in the CiA application note 802 almost suggests that the problem has been taken care of, but that is only true when certain rules are being followed:
- Network Management: Use heartbeat rather than node-guarding functions, since this does not involve remote frames.
- Polling of Process Data Objects (PDOs): Use a scheduling function for the transmission of PDOs; however, do not use remote frames for the scheduling. CANopen provides two modes, centralized and decentralized scheduling of PDOs (please refer to the CANopen standard DS-301 and DSP-302).
[1] As is pointed out throughout this document, the official description of the CAN protocol leaves ample room for interpretation. In this particular case it did lead to different results between chip designers.