Some basic questions about CAN bus uuids.

[Telescopic]

Some basic questions about CAN bus uuids.

The context is hobbyist/light commercial 3D printing. Information about automotive and industrial applications is interesting, too.

1. When and how is a uuid created?

2. Does a device create its own uuid?

3. If a device's flash memory is cleared (for instance, with STM32CubeProgrammer), is the uuid wiped out as well?

4. Is there a utility to list all powered devices present on a CAN bus, including their uuids?

5. (Bonus, just curious) Why are uuids not shown? What event triggers their cloaking?


This is my first post here. I need to understand this, and I hope others will find it useful too. Thanks!

 

[Spice_King]

I'll say up front that the way Klipper uses CANBUS is not in any standard protocol, where a whole message in a single CANBUS message, it's just a layer used to ship the Klipper protocol messages, instead of over serial (or USB emulated serial).

1-3: The CANBUS uuid is based off the MCU's internal chip serial number, UID, or what ever the given manufacture opts to calls it's flavor of a per chip unique read only value. You can see this in chipid.c in the Klipper source code for the MCU firmware, where there are 5 versions of it for differing MCU families. The STM32 family is the simplest, a magic chunk of memory just has it to read, SDK headers providing the address and length to read from. The chips unique ID is hashed down from what ever arbitrary size the manufacturer used into a 6 byte value we know as a canbus_uuid so it even fits in a CANBUS packet. I don't think there is a MCU which lacks a program accessible unique ID that is also allowed to setup CANBUS in Klipper, but in theory if there was, a fix for that bad chip design would be to encode a random ID into the firmware to use.

4. scripts/canbus_query.py exits

5. Once initalized by the klipper host process, it simply no longer responds to the uuid query as it has a runtime klipper MCU short single byte id to work with, and still responding just adds noise.

If you want the nitty gritty, it's all on https://www.klipper3d.org/CANBUS_protocol.html

 

[Telescopic]

Thanks, Spice_King, for a quick and informative response. I'm a bit embarrassed, feeling that I should understand this more deeply than I do. After seeing your response I looked at canquery.py and the can library and although I don't want to get that deeply into it, it's within my grasp with some work. The LDO Voron 0.2 I'm building will eventually be CANbus, but for now I'll go back to the Picobilical approach.

I've accumulated all the hardware required for CAN and I've got spare Pi4s lying around. I will put'em on a breadboard and fiddle with them--but only after the Voron is up and printing. I'm not going to think about CAN again until I've got some good benchies & I've printed the parts to resurrect my Prusa Mk2.5.