Keep Your Hands Off CAN Remote Frames –
and the Alternatives Available Today

The use of CAN remote frames has been controversial in practice for years. Although they are defined in the classical CAN protocol, they have proven of little value in modern systems. Many higher-layer protocols deliberately avoid them or even prohibit their use altogether. There are good reasons for this: in real applications, remote frames often lead to inconsistencies, implementation issues, and unnecessary complexity.

This is reinforced by the overall technological direction: remote frames are no longer part of CAN FD, and CAN XL does not include them either. That makes it clear that remote frames are now more of a legacy topic in classical CAN than a sensible foundation for new architectures.

A remote frame does not carry payload data itself. Its sole purpose is to request the transmission of a data frame with the same CAN identifier. What may look elegant in theory often causes difficulties in practice. One reason is that the way a CAN controller reacts to a remote frame is not implemented uniformly across devices.

A particularly critical case is the automatic response of a CAN controller to a remote frame. In that situation, data may be sent even though the application has not had a chance to verify or update it shortly beforehand. In the worst case, the controller responds with outdated information.

Another risk is that a CAN controller may continue responding to remote frames as long as its protocol engine remains active — even if the rest of the microcontroller or the application is already in a faulty state. This means a node may still appear functional from the outside while the actual application is no longer operating correctly internally. In safety-critical or diagnostically relevant applications, that is a serious issue.

The conclusion is therefore straightforward: keep your hands off CAN remote frames.

With remote frames, it often remains unclear how current the requested information actually is, which node is responsible in edge cases, and how ambiguities can be cleanly avoided. This complicates not only implementation, but also documentation and testing.

In the CANopen environment, remote frames were historically used or at least taken into account in specific services. The problem has been known there for a long time, and the article points to CiA Application Note AN802, which describes how CANopen networks can also be operated without RTR-based communication.

Node Guarding can simply be replaced by the Heartbeat service, with the added advantage that CANopen NMT slave devices can monitor one another, whereas Node Guarding can only be performed by the NMT master.

Requests for PDO messages can be replaced by a SYNC message, and the resulting behavior can be configured with much greater flexibility.

Remote frames are one of those features of classical CAN that may look interesting on paper but cause more problems than they solve in real systems. Inconsistent implementations, potentially outdated data, difficult testability, and the lack of support in modern CAN variants all argue clearly against their use.

The recommendation is therefore unambiguous: remote frames shall not be used. Instead, cyclic transmission, event-driven communication, or explicit request/response mechanisms using normal data frames are the more robust and future-proof solutions. The fact that CAN FD and CAN XL do without remote frames only underlines this recommendation.

/1/ ISO 11898-1, Road vehicles — Controller area network (CAN) — Part 1: Data link layer and physical signalling
/2/ CiA Application Note AN802 – Version 1.1.1, Avoiding CAN Remote Frames in CANopen networks