I heard many people say that CAN message have ID's and not nodes. I think this could be due to the fact that, irrespective of assigning a unique ID for each node, all nodes receive the messages. Also, in the event of any retransmission of a message, duplicate messages can be discarded when messages are assigned ID's when sending to each node.

But what if a system has 3 masters talking to many slave and all the 3 masters execute the same code(like in a 2 out of 3 voting system). In such an architecture, it makes sense of assigning each node a unique ID so that the slave knows which master sent it data and reply back to each master uniquely. Also, i cant think of a situation where a node may receive a duplicate message because retransmission occurs only in the event of error detection and when an error is signalled by a node, every node that received the data destroys the received data.

I'm confused now because i plan on assigning unique Id's to each node and the masters shall send message to each node based on its node ID(But the vast majority of CAN experts out there disagree with me). Assigning each message a unique ID would mean that,if Master A sends 500 messages,500 unique Id's out of 2048 possible ID's(11 bit identifier) must be used by Master A. Remaining 500 by Master B,and remaining 500 by Master C. Any insights on which would be a good approach would be greatly appreciated.

Also, any situation as to when a duplicate message can arrive at a node that already received the message would be of great help as that would be a solid explanation as to why each message must be given a unique ID and not a node. This will help me understand that if Master A always sends the same identifier,the receiver will have no way of differentiating if its a duplicate message or not.


I think you're misunderstanding this:

I heard many people say that CAN message have IDs and not nodes.

This doesn't mean that every message sent on the bus should have a unique ID, or that you should never be able to identify which node sent the message. It means that IDs are best used to indicate what kind of data is being sent, not where the data is going. For example, if you have a temperature sensor broadcasting data, you can assign an ID number to mean "temperature data from sensor #1". Then any node that cares about temperature data can receive it. Many (most?) CAN controllers can easily send and receive multiple IDs, so it often doesn't make sense to say that a node has only one ID.

In your case, you could make IDs for "command from master 1 to slave 5", "command from master 2 to slave 8", "response to master 3 from slave 7", etc. I don't know enough about your system to say whether that's the best way to do it.

I don't understand why slaves need to respond to each master separately. If this is a majority-vote system, shouldn't one slave response be enough? You could have separate message IDs for errors.

Remember that all nodes receive all messages. It's up to the node whether it stores the message or not.

| improve this answer | |
  • \$\begingroup\$ I thought of an ID scheme like this, ID= (Sender ID+Receiver ID). The receiver will check if the message belongs to it and also if it has permission to process the data from the Sender. The complete data cannot be processed in a single 8 byte CAN message. For complete decoding of a message a slave will have to give back approx about 5*8 bytes of data. Also what about the possibility of a duplicate message??? \$\endgroup\$ – AlphaGoku Mar 7 '16 at 6:49
  • \$\begingroup\$ Also if there are many slaves(ex:100 nodes), there is a probability that the lowest id slave(i.e : ID 4) will keep hogging the bus not allowing higher id's to send their data. Scenario: Slave 4 sends its data-->Small time to form new data,Slave 5 to 40 finished sending their data-->Slave 4 sends new data-->Repeat as above. Slaves 41 to 100 will never get the bus if this continues right? \$\endgroup\$ – AlphaGoku Mar 7 '16 at 7:05
  • \$\begingroup\$ It sounds like you want to implement a higher-level protocol with packetized data. There are a lot of ways you could do that. You could allocate a couple byte in the data for sequencing. You could switch to 29-bit IDs. It depends on the capabilities of your nodes. \$\endgroup\$ – Adam Haun Mar 7 '16 at 7:09
  • \$\begingroup\$ To keep nodes from hogging the bus, you need to limit their transmissions and keep the bus utilization low. CAN is a low-level protocol; it's doesn't handle this stuff for you like TCP/IP would. \$\endgroup\$ – Adam Haun Mar 7 '16 at 7:12
  • \$\begingroup\$ You might want to look into existing high-level protocols instead of designing your own: kvaser.com/about-can/higher-layer-protocols \$\endgroup\$ – Adam Haun Mar 7 '16 at 7:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.