I am learning about the CANopen implementation of CAN, but there is something I can't seem to understand. I was trying to see the differences between a standard CAN-frame and a CANopen SDO-frame. When laying these two on top of each other, I noticed some differences.
A "regular" CAN-frame is specified as:
| 1 | 11 | 1 | 1 | 1 | 4 | 0 - 64 | 16 | 2 | 7 |
|---|---|---|---|---|---|---|---|---|---|
| SOF | ID | RTR | IDE | reserved | DLC | Data | CRC | ACK | EOF |
While some links (for example) specify a CANopen SDO-frame as:
| 11 | 1 | 4 | 0 - 64 |
|---|---|---|---|
| COB -ID | RTR | DLC | Data |
It makes sense to leave out the SOF-bit and everything after the data-section for clarity.
But the thing I don't understand; why are the IDE-bit and reserved bit gone in a SDO-frame? Are they being sent even though they are not specified? Would they not specify it because it is part of the layers that implement CAN, and the CANopen layer has nothing to do with these bits?
Unfortunately I don't have access to a embedded device that supports CANopen, so I can not check it with a oscilloscope whether or not these bits would be sent.
There is no difference - your CANopen example is just an over-simplification.
The "OSI model" is prerequisite knowledge before studying any form data communication. CANopen is the application layer sitting on top of the CAN data link layer and physical layer. Comparing a CAN frame with a CANopen frame is like comparing a tire with a car.
In this over-simplification they chose to not include the SOF, IDE and a bunch of other things. Since CANopen mainly (only?) uses 11 bit identifiers, so the IDE bit is irrelevant. They also strive to remove dependencies of the RTR bit in favour of only using the data payload, which is one reason why the CANopen node guarding protocol is deprecated.