[et_pb_section fb_built=”1″ disabled_on=”off|off|off” _builder_version=”4.27.5″ _module_preset=”default” background_image=”https:\/\/blog.microcontrol.net\/wp-content\/uploads\/2026\/03\/MicoControl_Grundlagen_CAN.png” max_width=”95%” custom_margin=”0px||||false|false” custom_padding=”130px||0px|||” global_colors_info=”{}”][et_pb_row column_structure=”1_2,1_2″ _builder_version=”4.16″ _module_preset=”default” width=”100%” custom_padding=”0px||0px||false|false” global_colors_info=”{}”][et_pb_column type=”1_2″ _builder_version=”4.16″ _module_preset=”default” global_colors_info=”{}”][\/et_pb_column][et_pb_column type=”1_2″ _builder_version=”4.16″ _module_preset=”default” global_colors_info=”{}”][et_pb_image src=”https:\/\/blog.microcontrol.net\/wp-content\/uploads\/2021\/10\/MicroControl-Troisdorf-Germany.png” title_text=”MicroControl Troisdorf Germany” _builder_version=”4.16″ _module_preset=”default” width=”75%” module_alignment=”right” global_colors_info=”{}”][\/et_pb_image][\/et_pb_column][\/et_pb_row][\/et_pb_section][et_pb_section fb_built=”1″ _builder_version=”4.16″ _module_preset=”default” background_enable_color=”off” custom_margin=”||||false|false” custom_padding=”||||false|false” global_colors_info=”{}”][et_pb_row _builder_version=”4.16″ _module_preset=”default” custom_margin=”||||false|false” custom_padding=”||||false|false” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.16″ _module_preset=”default” global_colors_info=”{}”][et_pb_text _builder_version=”4.27.5″ _module_preset=”default” header_font=”||||||||” header_font_size=”32px” custom_margin=”||||false|false” custom_padding=”||||false|false” hover_enabled=”0″ global_colors_info=”{}” sticky_enabled=”0″]<\/p>\n
[\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.21.2″ _module_preset=”default” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.16″ _module_preset=”default” global_colors_info=”{}”][et_pb_text _builder_version=”4.27.5″ _module_preset=”default” header_3_text_color=”#ef7c00″ custom_margin=”0px||0px||false|false” custom_padding=”0px||0px||false|false” global_colors_info=”{}”]<\/p>\n
The use of CAN remote frames<\/strong> has been controversial in practice for years. Although they are defined in the classical CAN protocol, they have proven to be of little value in modern systems. Many higher-layer protocols deliberately avoid them or even prohibit their use at all. There are good reasons for this: in real applications, remote frames often lead to inconsistencies, implementation issues, and unnecessary complexity. <\/p>\n This is reinforced by the overall technological direction: remote frames are no longer part of CAN FD<\/a>, and CAN XL does not include them either. This makes clear that remote frames are now more of a legacy topic in classical CAN than a sensible foundation for new architectures. <\/p>\n [\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.21.2″ _module_preset=”default” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.16″ _module_preset=”default” global_colors_info=”{}”][et_pb_heading title=”Why Remote Frames are a Problem” _builder_version=”4.27.5″ _module_preset=”default” title_level=”h2″ hover_enabled=”0″ global_colors_info=”{}” sticky_enabled=”0″][\/et_pb_heading][et_pb_text _builder_version=”4.27.5″ _module_preset=”default” header_3_text_color=”#ef7c00″ custom_margin=”0px||0px||false|false” custom_padding=”0px||0px||false|false” global_colors_info=”{}”]<\/p>\n 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 seem an elegant way 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<\/strong>. <\/p>\n [\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.21.2″ _module_preset=”default” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.16″ _module_preset=”default” global_colors_info=”{}”][et_pb_image src=”https:\/\/blog.microcontrol.net\/wp-content\/uploads\/2026\/03\/Frame-Format-Base-Standard-RTR.webp” alt=”CAN-Bus: Remote Frame Format” title_text=”Frame-Format-Base-Standard-RTR” show_in_lightbox=”on” _builder_version=”4.27.5″ _module_preset=”default” global_colors_info=”{}”][\/et_pb_image][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.21.2″ _module_preset=”default” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.16″ _module_preset=”default” global_colors_info=”{}”][et_pb_text _builder_version=”4.27.5″ _module_preset=”default” header_3_text_color=”#ef7c00″ custom_margin=”0px||0px||false|false” custom_padding=”0px||0px||false|false” global_colors_info=”{}”]Depending on the controller architecture, the requested data frame may be transmitted automatically from a prepared message buffer, or it may have to be provided actively by the application. This is where the trouble starts: there is no consistently uniform behavior that developers can rely on. As a result, both software portability and systematic fault analysis become more difficult. <\/p>\n 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 beforehand. In the worst case, the controller responds with outdated information.[\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.21.2″ _module_preset=”default” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.16″ _module_preset=”default” global_colors_info=”{}”][et_pb_heading title=”Faulty or Inconsistant Implementations” _builder_version=”4.27.5″ _module_preset=”default” title_level=”h2″ hover_enabled=”0″ global_colors_info=”{}” sticky_enabled=”0″][\/et_pb_heading][et_pb_text _builder_version=”4.27.5″ _module_preset=”default” header_3_text_color=”#ef7c00″ custom_margin=”0px||0px||false|false” custom_padding=”0px||0px||false|false” global_colors_info=”{}”]In practice, remote frames are repeatedly found to be implemented incompletely or incorrectly. Problems range from improper handling of the DLC field to controllers that react to certain remote-frame situations by sending error frames. <\/p>\n Another risk is that a CAN controller may continue responding to remote frames as long as its protocol engine remains active \u2014 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. <\/p>\n The conclusion is therefore straightforward: keep your hands off CAN remote frames.<\/strong><\/em>[\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.21.2″ _module_preset=”default” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.16″ _module_preset=”default” global_colors_info=”{}”][et_pb_heading title=”Different Interpretations in Systems Design” _builder_version=”4.27.5″ _module_preset=”default” title_level=”h2″ hover_enabled=”0″ global_colors_info=”{}” sticky_enabled=”0″][\/et_pb_heading][et_pb_text _builder_version=”4.27.5″ _module_preset=”default” header_3_text_color=”#ef7c00″ custom_margin=”0px||0px||false|false” custom_padding=”0px||0px||false|false” global_colors_info=”{}”]Additional difficulties arise because remote frames effectively introduce an implicit request\/response mechanism at link-layer level. In a distributed system, it is usually much clearer and more robust to model requests and responses explicitly at application level. <\/p>\n 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.[\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.21.2″ _module_preset=”default” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.16″ _module_preset=”default” global_colors_info=”{}”][et_pb_heading title=”CANopen and the historic Exceptions” _builder_version=”4.27.5″ _module_preset=”default” title_level=”h2″ hover_enabled=”0″ global_colors_info=”{}” sticky_enabled=”0″][\/et_pb_heading][et_pb_text _builder_version=”4.27.5″ _module_preset=”default” header_3_text_color=”#ef7c00″ custom_margin=”0px||0px||false|false” custom_padding=”0px||0px||false|false” global_colors_info=”{}”]<\/p>\n In the CANopen <\/a>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<\/a>, which describes how CANopen networks can also be operated without RTR-based communication. <\/p>\n 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.<\/p>\n Requests for PDO messages can be replaced by a SYNC message, and the resulting behavior can be configured with much greater flexibility.<\/p>\n [\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.21.2″ _module_preset=”default” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.16″ _module_preset=”default” global_colors_info=”{}”][et_pb_heading title=”Conclusion” _builder_version=”4.27.5″ _module_preset=”default” title_level=”h2″ hover_enabled=”0″ global_colors_info=”{}” sticky_enabled=”0″][\/et_pb_heading][et_pb_text _builder_version=”4.27.5″ _module_preset=”default” header_3_text_color=”#ef7c00″ custom_margin=”0px||0px||false|false” custom_padding=”0px||0px||false|false” global_colors_info=”{}”]<\/p>\n Remote frames are one of those features of classical CAN<\/a> 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 are strong reasons against their use. <\/p>\n