The following is an excerpt from  A Comprehensible Controller Area Network by Wilfried Voss.

Experience over the years has revealed some quirks in the CAN Bus protocol, which are naturally not covered by any official document, and one of them has led to the call to avoid CAN remote frames. 

In August of 2005, CAN-in-Automation (CiA) published (but not promoted) their application note 802 - "CAN remote frame - Avoiding of usage."

The CAN Bus data and remote frames are very similar. The remote frame resembles a data frame without the data field (which would is 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 on the way the Control Field, particularly the data length code, is transmitted:

The present problem rests in protocol-incompatibilities between CAN Bus controllers from various manufacturers and how they manage the Remote Frame, which consequently will produce CAN message collisions.

A bus collision may occur under the following conditions:

• Two or more nodes in a CAN Bus network requested the same message at the same time.
• Remote frame and requested data frame access the bus at the same time (this condition is not mentioned in the CiA application note).
• The data length codes differ between the nodes.

Note: The remote frame and the requested data frame use the same message identifier. Both frames separate themselves through 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 concurrently, the data frame will gain the bus access over the remote frame since it applies a dominant RTR bit.

Remote frames can only be transmitted with a data length code (DLC) identical to the DLC of the corresponding (requested) data frame. Concurrent transmission of remote frames with different DLC's will result in irresolvable collisions, meaning the CAN bit monitoring feature will identify 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 identical message IDs try to access the bus. The result of such a scenario has so far not been documented in any official literature. The official statement is that such situations are not permitted and will lead to unpredictable results. However, as CiA application note 802 demonstrates, there are quite some discrepancies between the numerous CAN controllers available in the market and how they manage remote frames. It appears that collisions can occur with such a probability that the use of remote frames is not recommended at all.

Dual CAN Bus Interface For Arduino Due With Extended Power Range

The jCOM.CAN.DUE-X, a dual CAN bus interface for the Arduino Due, is not an Arduino shield in the common sense. 

The board incorporates dual CAN transceivers required by the two integrated CAN ports on the Arduino Due while allowing the operation with any Arduino-compatible shield that supports the necessary 3.3 VDC power requirements.

By combining our dual CAN port interface, the Arduino DUE microcontroller, an OBD2 or SAE J1939 cable, and open-source software libraries you are ready to go with powerful a turn-key Arduino-based dual CAN bus solution. 

Leverage the 32-bit processing capability of the Arduino DUE plus the built-in CAN ports for your next prototype.

In order to more efficiently serve automotive and industrial applications, the jCOM.CAN.DUE-X board supports an extended input power range of 7 to 36 VDC to power the entire system, i.e. including the Arduino Due itself.

More Information...