# Peer to Peer in CANopen - How does it work?

CANopen have something called an 11 bit COB-ID, it contains function code of 4 bits + node ID of 7 bits. For example:

Image from here.

Does this mean if the MASTER send a request to the CLIENT for example send a command to SDO. Then the COB ID will be (0b1100 << 7) | node ID in binary, because 0b1100 is the function code for SDO Receive.

So then the CLIENT got that request and then the CLIENT response back to the MASTER. Should the CLIENT respons with the SDO Transmit then e.g (0b1011 << 7) | node ID ?

That sounds terrible wrong because the COB ID request did not contain any source address like SAE J1939 does.

So if I send a SDO request to an CLIENT with the node ID 0x5, then the CLIENT response back with the same node ID 0x5 or is it another node ID e.g destination ID (in this case, node ID 0x0 because that's the master node ID)?

• All - The long comment chain has exceeded what is reasonable for comments. Therefore it has been moved to chat and should be continued there (link below). --- As this bulk moving of comments to chat can only be done once per question, any further comments posted here might be deleted without notice. Keep it in chat now, please! When someone has got enough information from the chat to post an answer, then please do that as usual. Any updates to the question which are decided during the chat, should be made via an edit to the question, not as a comment. Thanks. Oct 27, 2021 at 18:51
• Comments are not for extended discussion; this conversation has been moved to chat. Oct 27, 2021 at 18:51
• @SamGibson: Converting comments to chat which have technical value and are not argumentative is an misuse of moderator tooling (according to Meta, I can dig out the links if you like). Please don't do that. Oct 27, 2021 at 19:11
• @BenVoigt - Hi, Yes, please do dig out the link. I respectfully disagree with your claim of "misuse of mod tooling". I have read moderator guidance to the contrary of what you describe, stating that long comment chains themselves, irrespective of the contents, should be moved to chat (as large amounts of comments are not what comments were intended for). Please start a topic on Meta to discuss - not here. Thanks. Oct 27, 2021 at 19:21
• @BenVoigt - Thanks. As it says at the top of that linked page: "This question is only applicable to one specific site on the Stack Exchange network" (in that case it's Stack Overflow). I will add it to my to-do list, to see if I can find the different guidance which I am following (please note we have lots going on, with various urgent things). Since I'm not the only mod following the principle I described, and as I asked before, please start a Meta topic to discuss. Then we can get input from others. To avoid this becoming a Meta discussion here, I'm locking these comments. Thanks. Oct 27, 2021 at 19:50

There is no master, there is no client. Please don't invent your own terms which don't exist in CANopen, it's very confusing for yourself and others. There is just a sender and a receiver.

Then the COB ID will be (0b1100 << 7) | node ID in binary, because 0b1100 is the function code for SDO Receive.

Yes. So for example to configure node 1 you'd send a SDO with COBID 0x601. The node will respond with 0x581. In this case, node 1 does not care who the request comes from, only that it was addressed to node 1. Similarly, it doesn't care who picks up the response, because that is irrelevant. SDO is used to configure one single node, so only that node's id is relevant to the communication.

So the simplest and most common form of SDO communication is just a "ping pong" of 0x601 + 0x581 back and forth between the two nodes involved. Other SDO protocol versions exist, in order to utilize the bus more efficiently with less overhead, but that's another story.

Also notably you can re-configure all COBID to something else, what you see in that table is just the standard default settings. For example one node's TPDO must be another node's RPDO or they won't communicate. This pairing and configuration is exactly why CANopen is far from "plug & play", you must typically set up every node on the bus to suit the system design.

• Well. Lots of documentation says "master" and "slave" and "client" e.g Baumer Eletric and Siemens. So in this case, if the "client" is going to send to the "server", then the "server" will be the device e.g sensor and the "client" will be for example...me/the user? I send a COB-ID to the device and the device answer back to me. Then I save data in the OD if I'm requesting for example download SDO request.
– DanM
Oct 28, 2021 at 9:44
• @MrYui So read the actual CANopen standard. It's free after all. Client/server has a well-defined meaning in computer engineering and this is not it. Oct 28, 2021 at 9:53
• The standard is not written in the best way. I have lots of questions about it for example why there must be COB-ID's in the OD where a bit field describe if the COB-ID is valid or not valid. I don't find that very useful.
– DanM
Oct 28, 2021 at 10:23
• Hi Lundin. This is why I got confused. byteme.org.uk/canopenparent/canopen/… Se how they are using the request terms. Request Server -> Client (0x600 + Node ID)
– DanM
Oct 28, 2021 at 19:35