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.