Understanding CAN-FD Message Structures

crispus

I have a Duet 3 connected to a Toolboard via a Tool Distribution board.

For no particular reason, I would like to understand more about the data which is exchanged between the Mainboard and the Toolboard. To this end, I have connected a Teensy 4 and am receiving CAN-FD frames.

My next task is to understand how to unpack the data based on message ID. Could anyone offer any pointers regarding the messages I should expect to see and how the data is packed?

Thanks,

Christian

nhof

This post is deleted!

dc42

See https://github.com/Duet3D/CANlib/blob/master/doc/Duet 3 CAN protocol.odt for an overview.

crispus

Thank you, this is exactly what I needed.

Best Regards,

Christian

crispus

@dc42 Thanks again for your help, I have made good progress based on the information that you shared.

May I ask a follow up question?

When I receive timeSync messages (type 30) I am only seeing 64 bits, enough to unpack 'timeSent' and 'lastTimeSent'. I was expecting another 64 bits containing 'lastTimeAcknowledgeDelay' and 'realTime' but never see them. Is this expected or do I need to start investigating where the other 64 bits have gone?

Many Thanks,

Christian

Edit: oops - Corrected 64 bytes to 64 bits

dc42

@crispus said in Understanding CAN-FD Message Structures:

@dc42 Thanks again for your help, I have made good progress based on the information that you shared.

May I ask a follow up question?

When I receive timeSync messages (type 30) I am only seeing 64 bits, enough to unpack 'timeSent' and 'lastTimeSent'. I was expecting another 64 bits containing 'lastTimeAcknowledgeDelay' and 'realTime' but never see them. Is this expected or do I need to start investigating where the other 64 bits have gone?

Many Thanks,

Christian

Edit: oops - Corrected 64 bytes to 64 bits

Which firmware version are you using? The 'realTime' field was added after the initial release, and in the latest 3.3 firmware it is only included when the time has changed.

crispus

I am currently using the 3.2 release.

dc42

That's odd, because realTime is working in the 3.2 release.

crispus

Here are two consecutive messages:

ISR - MB 16  OVERRUN: 0  LEN: 16  EDL: 1 EXT: 1 TS: 53390 ID: 1E007F Buffer: 2B D1 92 DB 3A 87 90 DB 0 0 0 0 0 0 0 0 
ISR - MB 16  OVERRUN: 0  LEN: 16  EDL: 1 EXT: 1 TS: 56781 ID: 1E007F Buffer: 1A 1B 95 DB 2B D1 92 DB 0 0 0 0 0 0 0 0

I am receiving 16 bytes but as you can see, the last 8 are always zeros. Looking at the first 8 bytes, I can see the current 'timeSent' become the 'lastTimeSent' in the next message.

Phaedrux

Double check your installed firmwards with M122 and M122 B1

crispus

@Phaedrux thanks for the suggestion. Here is what I get:

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.2 running on Duet 3 MB6HC v1.01 or later (SBC mode)
Board ID: 08DJM-956BA-NA3TN-6JTD2-3S46M-9BAYS
Used output buffers: 1 of 40 (10 max)

M122 B121
Diagnostics for board 121:
Duet TOOL1LC firmware version 3.2 (2021-01-05)
Bootloader ID: SAMC21 bootloader version 2.2 (2021-01-16b1)

dc42

The realTime field will be zero until you connect to the Duet from DWC, at which time DWC sends the current time to the Duet. Until then, the Duet doesn't know the time.