CAN Remote Frames on Recall

 

The Controller Area Network (CAN) protocol, since its official introduction in 1986, has been - strangely enough - the object of continued research up to this day, since the official literature (CiA/Bosch specification and ISO11898) provides only superficial information. In addition, 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 'Contact Us' section on their web site (http://www.can-cia.org).

 

Before going into details, let's have a brief look at the CAN message frames:

 

        Data transfer from one sending node to one or numerous receiving nodes.

        Any node may request data from one source node. A remote frame is consequently followed by a data frame containing the requested data.

        Any bus participant, sender or receiver, may signal an error condition at any time during a data or remote frame transmission.

        A node can request a delay between two data or remote frames, meaning that the overload frame can only occur between data or remote frame transmissions.

 

Note: The creation of an overload frame was necessary due to the technology available in 1986. Considering the performance increase over the years an overload frame should not occur at all in a proper functioning network.

 

Let's now focus on the remote frame architecture:

 

http://www.cannewsletter.com/images/RemoteFrame.jpg

 

Both, 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:

 

http://www.cannewsletter.com/images/ControlField.jpg

 

A bus collision may occur under the following conditions:

 

 

 

Note: 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: