# CAN data transmission

I have four separate nodes (A, B, C, and D) that will transmit via a common CAN bus. For a full packet of data to be sent to a node, each CAN controller has to send three times (20 bytes of data).

Node A, B, and C request data from D.

A has a lower ID than B, B has a lower ID than C, but greater than A.

My question is: If A sends its first packet to D and is almost about to send the second packet (delay due to loading of data into transmit registers), and if B detects that the bus is idle, will B begin to send?

Even if B begins to send, if A's transmit buffer has been loaded, will A send? If A sends data, will D receive the data uncorrupted?

Note: I'm thinking of implementing time slots for each node A, B, C (but I won't be using the full potential of CAN).

• Your updated question still demonstrates a clear lack of understanding of how CAN works. Nodes do not have addresses/identifiers. Messages have identifiers. Lower-numbered identifiers have precedence on the bus. The concept of "a message to node X" does not exist in CAN. Apr 28, 2015 at 19:25

All CAN messages are broadcasts. Therefore a message from one node to all the other nodes only needs to be sent once. In fact, it can't be sent just to a individual node. That's not how CAN works.

You need to learn about CAN before proceeding any further.

• i do understand that the message is broadcasted and all nodes receive the message. My question was that Nodes a,b,c want to send to D. All 3 nodes run on the same code and so there are chances that all 3 of them may transmit at the same instant of time. Each node has 3 packets of message to send as stated above. Apr 21, 2015 at 4:42
• @0x6d64- I would appreciate it if you could let me know the answer and not pass references elsewhere. If Node A sends continuosly(assume upto (infinity -1) second),will node B wait upto infinity second to transmit its data??? Or will an error flag be set?? Apr 21, 2015 at 12:15
• @Akshay: As I already said, you need to learn about CAN before attempting to implement a system based on it. Go read the CAN spec. Apr 21, 2015 at 12:26
• I agree with Olin: you need to put in the effort to read the spec first. Otherwise you will get stuck a lot of more small hurdles that will come along and end up with a system far from using the "full potential of CAN" as you want it. Apr 21, 2015 at 17:25
• @Akshay: for me, it's the first result when I google for "CAN specification" Apr 22, 2015 at 13:25
1. CAN nodes don't have an ID, the messages they send have one (if every node only transmits only one message, you could think of the ID of that message as the "node ID", but this is not the normal case).

2. Any CAN controller will stop transmitting once it sees a message with a lower ID that currently written on the bus (the other node can continue without interruption, this is called arbitration). So CAN makes sure that there is no collision. However, there can be the case that a node transmits a high priority message (= low ID) repeatedly and the other nodes can't send their messages. You as the designer of the network are responsible to make sure that this does not happen (e.g. limit how often a message ist sent). If you can not tolerate certain delays you have to keep the bus load unter a certain threshold so that even in the worst case the message can be transmitted in time.

You need to learn about CAN; it's message-centric, not node-centric. If A, B, and C all want the same message from D, they'll all send the same ID with the RTR bit set and a DLC of zero. Since the messages from A, B and C are identical and if they're all sent at the same moment, there will be no collision (assuming the bits all arrive at the same time). If you're monitoring the bus you will see a single message with the RTR bit sent and then the response from D, which A, B, and C will all see.

To answer your broader question: CAN nodes generally won't transmit if they see the bus is busy, and they wait until the inter-message time has passed before attempting to send. So "will A send if B's message has been sent?" -- first of all, A, B, and C will all "see" their message was sent as there was no bus collision in the scenario above. Second, it depends on your software design. The hardware usually takes care of getting the message on the bus, but your software logic dictates whether "Part B" gets sent if "Part A" is still pending or failed to send.

This has nothing to do with CAN itself and everything to do with your higher level protocol design.

• I agree with what you are saying except a minor nit. Even on small microcontroller, it is usually the hardware that decides when exactly to send a message. The hardware waits for the bus to be idle, detects collision, and tries to re-send at the next opportunity until the message is eventually sent. This therefore is generally not up to the high level protocol. Apr 26, 2015 at 12:59
• You're right; the hardware does all the detection and delays. I had meant that it's the higher level software that decides whether to send "Part B" or not, and that decision can include "did Part A send?" checks. Apr 26, 2015 at 13:24
• So your saying allot time slots for each transmission from a node so that even if a node fails after a first frame has been sent,the other nodes will not send their data until their set time. Apr 27, 2015 at 4:57
• @Akshay no, that's not what I'm saying at all. Please read about CAN. Apr 27, 2015 at 5:25