CANBus response using RTR

I'm implementing a Canbus network with multiple nodes (using MCP2515 chips). I've got 4 or 5 nodes which communicate fine with each other, using this library : GitHub - coryjfowler/MCP_CAN_lib: MCP_CAN Library

I want to implement some 'heartbeats' between the master node and the sensing nodes to ensure that they are live on the network, and I would assume that an RTR to each node would be a workable approach. (I would use filters to ensure that there are unique heartbeat CanIDs for each node).

I don't currently understand the mechanism by which the requested data frame is populated and transmitted.

My question is : on the node that receives the request, do I need to monitor specifically for an RTR and include code to load data in the requested data frame, or does the hardware automatically send it back populated just with zeros / empty)? I have seen some references to it being managed by the hardware and requiring no CPU, but is this the case? If not, then would I just have a pre-populated message with the correct ID sitting there waiting to be sent back, which happens when the RTR comes in?

Anything that helps demystify the population / transmission process would be gratefully received.

I could be wrong but I don't think the MCP2515 has any auto-responder functionality that deals with RTR messages. The Arduino code will need to spot the the message and send an appropriate response.

In my projects I don't use RTR or any other request/response system for heartbeats. Instead I just program each node to automatically send a low priority heartbeat message every second or so. The automatic priority system ensures these don't delay more important messages from other nodes.

The only real advantage of a request/response system is that it allows you to precisely control the amount of traffic on a bus, useful on a high traffic bus, but on a low traffic bus it just adds another level of complexity for little gain.

Thanks, that makes sense. It would be nice to have a process that is managed in the background, especially as the RTR bit can be set in the sending data frame with this library. Anyway... I'll see what I can do with this approach.

Using RTR is fine and all if you know the caveats, but I still recommend avoiding its usage.

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.