Hi there,

I've been looking about the CAN protocol, specifically the concept of multi-master, but I'm a bit confused. I get that each node can send and receive messages on bus. When a node sends a message, all the others receive it, and interested nodes can decode it.

But I'm struggling to understand what "multi-master" really means. Does it mean that many nodes can talk to each other, but not at the same time? Or is there something else to it?

Could you explain what "multi-master" means in simple terms for me? I'd really appreciate the help.

Thanks a lot!

@Papabravo

 

Multi master or master in general is not a concept in CAN networks. A "master" device controls all aspects of the signaling on the bus. The slave devices cannot "talk" to the master. The master has to request data from the slave.

In a CAN network all devices take turns sharing information. In a master / slave network the master initiates all communication with the slaves.

 

Multi master or master in general is not a concept in CAN networks.

However, the specifications show a multi-master terms, please refer to the image provided below.

 

However, the specifications show a multi-master terms, please refer to the image provided below.
View attachment 318275

Multi-master capability meaning any node on the bus can initiate communication to any other node in a network.

How you design your upper level protocol is up to you.
You can setup your protocol so that some Masters are more Masterful than others.

 

Thank you for clarification nsaspook

I'm trying to understand decision to select an 11-bit identifier or a 29-bit identifier.

From what I've gathered, if our application involves a limited number of unique messages communicating on the CAN bus, the 11-bit identifier might suffice. It offers up to 2,048 (2^11) unique message IDs.

Considering this, I'm interested to hear from the community about their experiences. What factors did you consider when choosing between the two identifier lengths

 

Thank you for clarification nsaspook

I'm trying to understand decision to select an 11-bit identifier or a 29-bit identifier.

From what I've gathered, if our application involves a limited number of unique messages communicating on the CAN bus, the 11-bit identifier might suffice. It offers up to 2,048 (2^11) unique message IDs.

Considering this, I'm interested to hear from the community about their experiences. What factors did you consider when choosing between the two identifier lengths

I would use the most modern and flexible version of CAN (CAN 2.0B as a starting point) that's compatible with the hardware I have, if designing from scratch. The 11-bit message ID and 29-bit message ID) may coexist on the same CAN bus and most can controller hardware can easily switch between the two.
https://matthewcmcmillan.blogspot.com/2015/02/arduino-can-bus-and-29-bit-extended-ids.html

 

Thank you for clarification nsaspook

I'm trying to understand decision to select an 11-bit identifier or a 29-bit identifier.

From what I've gathered, if our application involves a limited number of unique messages communicating on the CAN bus, the 11-bit identifier might suffice. It offers up to 2,048 (2^11) unique message IDs.

Considering this, I'm interested to hear from the community about their experiences. What factors did you consider when choosing between the two identifier lengths

It is all about dividing up the identifier space. The prime rule on a CAN network that: "two distinct nodes on a CAN newtwork CANNOT produce messages with identical identifiers". Each node on a CAN network must have a unique set of identifiers that it alone is allowed to produce. All nodes can be configured to consume a set of identifiers and these sets do not have to be disjoint. The responses however, must be disjoint.

The reason for all this is that if two nodes produce the same identifier then the CAN arbitration mechanism could bring the network down if both nodes retry the doubly successful arbitration, proceed to the rest of the message and throw error frames the first time a dominant bit steps on a recessive bit. This process might potentially continue without resolution.

In short: Duplicate message identifiers in a CAN network is VERY BAD JUJU.

 

I would use the most modern and flexible version of CAN (CAN 2.0B as a starting point) that's compatible with the hardware I have,

Does the choice of CAN protocol version depend on its compatibility with the hardware being used?

For instance, if I have hardware that supports CAN 2.0B but not CAN FD, would it be more practical to stick with CAN 2.0B ?

 

Unless you have a really compelling reason to develop your own protocol on top of CAN, I would advise you to start by implementing an existing protocol. There really is no best one out there and the experience will teach you what to look for. You should assume that there is something about every protocol that sucks. You won't know what that is without some experience. As much as I know about CAN, I don't think I would have a prayer of covering all the bases that the guys at Bosch, Honeywell, Allen-Bradley, Kvaser, and others were able to do. They had multiple years on multiple networks behind their decision making. We were lucky to stand on the shoulders of giants.

 

In short: Duplicate message identifiers in a CAN network is VERY BAD JUJU.

I'm a bit confused about how error detection works. In the CAN protocol, when one node transmits a message and other connected nodes receive it, I'm wondering: does only the receiver node check for errors, or do both the sender and receiver nodes check for errors?

I'd appreciate any clarifications on this.

 

Does the choice of CAN protocol version depend on its compatibility with the hardware being used?

For instance, if I have hardware that supports CAN 2.0B but not CAN FD, would it be more practical to stick with CAN 2.0B ?

It's obvious that it does depend on the hardware being used, down to using compatible transceivers..

Practical is relative to your application. For my simple closed canbus, I used CAN FD (and selected a controller with it) because of the speed (5MHz) and 64 byte payload can easily update remote LCD displays several times a second without loading the physical bus. The number of ID's wasn't a deciding factor as I only used a block of 16 for the filters.

 

I'm a bit confused about how error detection works. In the CAN protocol, when one node transmits a message and other connected nodes receive it, I'm wondering: does only the receiver node check for errors, or do both the sender and receiver nodes check for errors?

I'd appreciate any clarifications on this.

The answer is that everybody on the network checks what goes out, regardless of the settings for any mask and match registers, including the originator of the message. Any node on the network can, and will, throw an ERROR FRAME which consists of enough dominant bits to violate the bit stuffing rule. Ultimately every node on the network will eventually throw an ERROR frame. Once all those ERROR frames die down normal operations can resume.

It should be obvious from the existence of the bit0 and bit1 errors that only the transmitter can make that determination.

 

The answer is that everybody on the network checks what goes out, regardless of the settings for any mask and match registers, including the originator of the message. Any node on the network can, and will, throw an ERROR FRAME

I'm seeking clarification on error detection and handling processes, particularly regarding the definition of an 'error.'

Is a transmission problem considered an error, or is it only when a message violates specifications?

 

I'm seeking clarification on error detection and handling processes, particularly regarding the definition of an 'error.'

Is a transmission problem considered an error, or is it only when a message violates specifications?

https://onlinedocs.microchip.com/ox...UID-B8B540CB-5C71-43F8-B208-177220B8CE0A.html

According to the CAN Specification (see ISO 11898-1, 6.3.3 Recovery Management), the CAN provides means for automatic retransmission of frames that have lost arbitration or that have been disturbed by errors during transmission. By default automatic retransmission is enabled. To support time-triggered communication as described in ISO 11898-1, chapter 9.2, the automatic retransmission may be disabled via CCCR.DAR bit (CCCR <6>).

Take the time to actually read the specification.

 

Could you help clarify something for me?

If a sender node sends a message to a receiver node, but the receiver node receives a corrupted message with incorrect bits or an incorrect format, would that be considered an error according to the specifications?

I'm unsure whether my understanding is correct, and I'd appreciate some clarification on this matter.

Thank you.

 

Could you help clarify something for me?

If a sender node sends a message to a receiver node, but the receiver node receives a corrupted message with incorrect bits or an incorrect format, would that be considered an error according to the specifications?

I'm unsure whether my understanding is correct, and I'd appreciate some clarification on this matter.

Thank you.

Take the time to actually read the specification.

 

Could you help clarify something for me?

If a sender node sends a message to a receiver node, but the receiver node receives a corrupted message with incorrect bits or an incorrect format, would that be considered an error according to the specifications?

I'm unsure whether my understanding is correct, and I'd appreciate some clarification on this matter.

Thank you.

The only error a receiver can detect would be a CRC error, or some kind of bit error where only one possible value is expected. In practical terms a CRC error is almost impossible to imagine. The most likely errors are detected by the transmitter when it transmits a recessive bit and hears a dominant bit. Usually, it will not be possible to transmit a dominant bit and hear a recessive bit.

 

I need someone to clarify my doubt from a practical point of view regarding the number of messages needed for the given requirements.

(hypothesis) In a vehicle, headlights can be turned on or off using buttons, and the temperature and humidity values will be displayed on a display installed in the car.

System consists of 4 nodes:

1. First Node: Here, there are 2 switch buttons to control two headlights.
2. Second Node: There are 4 switch buttons to open/close the 4 doors of the vehicle.
3. Third Node: This node monitors the temperature and humidity inside the vehicle.
4. Fourth Node: This node displays the temperature and humidity data.

Question : How many messages are required for the entire system ?

1. First Node:
   • It requires two messages to control the headlights (one to turn on and another to turn off).
   • So, two messages are needed for the first node.
2. Second Node:
   • It receives commands to control the doors but doesn't need to transmit any messages.
   • No messages are needed for the second node.
3. Third Node:
   • It requires one message to transmit the temperature and humidity data.
   • So, one message is needed for the third node.
4. Fourth Node:
   1. It receives the temperature and humidity data from the third node, so it doesn't need to send any messages.

Therefore, a total of three messages are required for the entire system to fulfill the given requirements

Thank you for your help! @Papabravo

 

You understood what multi-master meant in this thread you started, did you forget?

 

You understood what multi-master meant in this thread you started, did you forget?

No, I understand the concept of multi-master configuration.