[FR] CAN bus

[Grogyan]

I have been toying with the idea for a few weeks now about unifying some of the communications with 3D printers. And thereby future proofing the 3D printer market.
One of these ideas, is looking at potential communication protocols/buses.
It came to conclusion that the use of a CAN bus could help streamline some of the control and sensing. Getting diagnostics, where available is also nice.

While things like the Trinamic 2130 can be interfaced to with a CAN to SPI bridge.
With CAN, external peripherals, like the common Remote Display (eg RepRapDiscount Full Graphic Display) could be easily extendable.
Though in the case of existing Remote Display's an interface controller would be needed, however, with bringing the code out of the main trunk, to enable Remote Displays to operate on a CAN, would alleviate the main processor of that extra processing overhead, and use those resources for printing, then just update the user as often as required.

The other thing too here is, what to do with the external SD card slots that are on these displays?
I have never been a fan of such long, and unshielded ribbon cables, which run via SPI on them. In future proofing, I would expect new Remote Displays to be engineered with USB (Type C connectors? Please?) thumb drive support, as these have shielding already, and are already designed for hot swap, whereas SD cards are not.

Question then is, would it be possible to have Marlin 2.x to incorporate CAN as a protocol/bus?

Disclaimer:
This is just a proposed idea.
I am not a coder at heart, and only do rudimentary dabbling from time to time.

[bobc]

CAN is great, I love it! It might be good for remote displays, but onboard it adds a lot of cost but presents little benefit. Trinamic 2130 can not be interfaced to CAN with a CAN-SPI bridge, it needs an MCU to handle CAN. To get the best out of CAN, it really needs to be native to the MCU, going via an external CAN controller over SPI kills the performance advantage.

Personally I would stick with SPI/I2C for everything on the main controller board and use RS485 or CAN for comms to remote devices such as LCD, smart toolheads etc. Cortex-M3 MCUs often have CAN,

Anyway, we can blue sky as much as we like, but what you are proposing is a new hardware platform that does not exist. Perhaps if someone builds the hardware, we could consider adapting Marlin for it.

[Grogyan]

Yes, have had a quick chat with Trinamic, and they don't (yet) have a driver that as inbuilt CAN support.
Hence the discussion.

I reckon that to have a future proof plan, which would then lead to silicon designers to integrate CAN is the best move.
Not just motor drivers, but also thermocouples and RTDs, filament sensors etc.
But it would require that those silicon designers realize the benefits to have their devices use CAN.

[alexxy]

Some projects for can controlled closed loop steppers already exist.

[tampas]

I'am really interested on this feature. I've been struggling with poor performance of SPI on medium range cable (over 2,5~3meters).

[alexxy]

Another possible protocol for can bus https://uavcan.org/

[Grogyan]

It is based on CAN FB by the looks of it. Still waiting for some CAN bus firmware support

[Blaster1920]

Ananas are now launching a new board: https://www.ogadget.com/x/ananasstepper3

[TVAVAE]

Is CAN or RS485 already supported by Marlin?

[Grogyan]

No, CAN or RS485 is currently not supported in Marlin 2.0
RS485 is a Master-Slave
CAN is Master-multi Slave

It is already implemented on the Duet 3 boards, which are not yet in production.

[TVAVAE]

You have info of CAN or RS485 in Marlin? Our board "VAkE" is already supporting Marlin 2. But we want a new board with one of the two buses ...

[Grogyan]

Best to go for CAN then.

CAN bus protocol is currently not supported in Marlin.
Sorry I had I typo before

[Grogyan]

There is a lot of work underway to get new 32bit boards set up and working.
Devs are working hard to get to a finalized version done.

It sounds like this is something which needs to be implemented soon @thinkyhead might know more

[alexxy]

I think another problem is that enabling can bus in Arduino like frameworks not a good idea.

With can bus you can build some distributed system (network of uC) in which each uC can control for example one stepper or one heater or one endstop. But it requres some kind of RTOS and huge redesing in MarlinFW

[Grogyan]

Is this something that will likely come in Marlin 2.1?

Several people I have talked to, want to use Marlin, but due to lack of support for CAN Bus, they have since moved onto using RepRap firmware on the Duet3D.

[geraldjust]

Hey guys, anyone is still interested in canbus? I just made a board to test it out. Anyone that could help to integrate this into marlin would be alot of fun! I have a ton of canbus experience but would still need some help.

https://github.com/geraldjust/3d-Printer-canbus-board

[Grogyan]

Teaching Tech did a review on a new affordable option for tool changing.
However many people will be disillusioned by the possibilities of adopting such technology.
This is due to the myriad of different tools/effectors, and also limits options on current boards.
The only option is to use CAN Bus, with the different drive electronics for each tool, on the tool itself

[Atanasovgoran]

Yes, I've wanted this for months.

I tried to implement it myself, but it was way over my head.

It would be great to use for end-stops. Actual position reporting (using Chinese calipers com protocol on a slave cheap)

or even motors.

It would simplify electronics, but this approach would increase costs if you did everything over can.

Not sure if the 1Mbps of can bus is fast enough even the new standard that allows faster speeds is 5Mbps. (is called Variable speed or something)

Also that way we could have a Mainboard with complete USB C connectors.

to power daughter boards and supply them with 12/24V
Can bus
i2c
maybe 5V or simply step it down at the other side.

I have build a few USB C breakout boards, but they don't have enough pins.

(and yes i know 24V is out of spec for c.

[Atanasovgoran]

Although it migh be better to fork the base code of Marlin and do a rewrite, because it would probably be impossible to intergrade it while support the centralized approach for other boards.

[geraldjust]

@Atanasovgoran If you can work with that i can go ahead and try and help you in organizing the canbus data and or make hardware for "heads" or something for example.

[Atanasovgoran]

@Atanasovgoran If you can work with that i can go ahead and try and help you in organizing the canbus data and or make hardware for "heads" or something for example.

Yeah, we could give it a try. How do we start? Do we create a Repo fot that? I am planning to buy some canbus boards arduino boards just to experiment and try moving some Motors for testing.

[Grogyan]

@Atanasovgoran start out with another fork of Marlin I think is easiest.
As Marlin will have to synchronize CAN and non-CAN devices.

Though in the distant future, mainboards would no longer require dedicated circuits.

Though a 6 pin interface will be required
2 For CAN power (which is typically 5V)
2 For CAN data
2 For high power (eg 12VDC or 24VDC)

[Atanasovgoran]

@Atanasovgoran start out with another fork of Marlin I think is easiest.
As Marlin will have to synchronize CAN and non-CAN devices.

Though in the distant future, mainboards would no longer require dedicated circuits.

Though a 6 pin interface will be required
2 For CAN power (which is typically 5V)
2 For CAN data
2 For high power (eg 12VDC or 24VDC)

Yeah, that's why i thought USB - C could work. out of the 12 (there are 24 but it's reversable) 2 are ground and 2 are VCC (say 12-24V (although out of spec)

The middle USB 2.0 should be thicker so 5V (shared ground with VCC)

that leaves 6 conductores.

I was thinking CAN Main, i2c and CAN aux. just in case the speed is not enough for everything. CAN main for motors and rest is CAN aux. And still i2c for display. so even display could use the same cable

[Grogyan]

"Not sure if the 1Mbps of can bus is fast enough even the new standard that allows faster speeds is 5Mbps. (is called Variable speed or something)"

This one area that appears to be a hurdle, but isn't, as optimizations between controller and node can be introduced

A naive approach could be to parse only extruder moves (extruders are used in tis example, however a myriad of other effectors can be optimized as well), and every say 3 extruder moves, set if necessary temperature and fan PWM values

[Blaster1920]

May I suggest you to use can-fd? You can find Dev boards for Arduino and RPI, plus you get all those sweets add-ons and potentially 8 Mbit/s, given how simple are 3d printers noise wise compared to automotive applications. Can is already being replaced by CAN 2.0, so it makes no sense to start with an old standard.

…

On Sun, 27 Dec 2020, 23:41 Grogyan, ***@***.***> wrote: "Not sure if the 1Mbps of can bus is fast enough even the new standard that allows faster speeds is 5Mbps. (is called Variable speed or something)" This one area that appears to be a hurdle, but isn't, as optimizations between controller and node can be introduced A naive approach could be to parse only extruder moves (extruders are used in tis example, however a myriad of other effectors can be optimized as well), and every say 3 extruder moves, set if necessary temperature and fan PWM values — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#7735 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACWD5UDOKWJ753WEEIYWRU3SW6ZYBANCNFSM4D4I4CAA> .

[Grogyan]

Yeah, that's why i thought USB - C could work. out of the 12 (there are 24 but it's reversable) 2 are ground and 2 are VCC (say 12-24V (although out of spec)

The middle USB 2.0 should be thicker so 5V (shared ground with VCC)

that leaves 6 conductores.

I was thinking CAN Main, i2c and CAN aux. just in case the speed is not enough for everything. CAN main for motors and rest is CAN aux. And still i2c for display. so even display could use the same cable

USB C, must ensure that the cable itself has twisted pairs, as required by the CAN standard

[sl1pkn07]

Hello

i have interest on this for my re-arm + ramps board. the re-arm expose the CAN1 port (Rx:P0.0 and Tx:P0.1) in the I2C port

greetings

[rondlh]

Here a project that connects a tool head via CAN bus.
Both the motherboard and toolhead run Marlin based on ESP32.
https://github.com/markniu/PandaCAN

I want to do something similar with a MKS Monster8 (STM32F407) and a MKS THR42 tool head (RP2040 based).
This code: https://github.com/thinkyhead/Marlin/tree/bf2_wip_rp2040_skr_pico_PR
is already very functional, I just have an issue running the onboard TMC2209 in the tool head, when I enable the driver it uses softwareserial, which causes a conflict on the RP2040 side, even the host communication breaks down.

I've been looking into the issues with softwareserial on the rp2040 of a MKS THR42. There seems to be a resource conflict with the timers I guess. With the following code I managed to send some commands to the TMC2209, but reading still fails, all received data is 0. I use this softwareserial: https://github.com/pkElectronics/SoftwareSerialM#master

#define TMC_BAUD_RATE 19200
#define RX_PIN            6
#define TX_PIN   RX_PIN
SoftwareSerial tmc_sw = SoftwareSerial(RX_PIN, TX_PIN); 
TMC2209Stepper driver = TMC2209Stepper(&tmc_sw, 0.11f, 0); // Rsense = 0.11ohm, address = 0
tmc_sw.begin(TMC_BAUD_RATE);

[thinkyhead]

Here a project that connects a tool head via CAN bus.

Thank you for the info! I expect we'll get CAN bus into shape for the next release following Marlin 2.2, which should be out soon. Just working through some issues in FT Motion and cleaning up scattered bugs.

[Grogyan]

Here a project that connects a tool head via CAN bus.

Thank you for the info! I expect we'll get CAN bus into shape for the next release following Marlin 2.2, which should be out soon. Just working through some issues in FT Motion and cleaning up scattered bugs.

This is fantastic news Scott.

Thanks for the update.

[rondlh]

Thank you for the info! I expect we'll get CAN bus into shape for the next release following Marlin 2.2, which should be out soon. Just working through some issues in FT Motion and cleaning up scattered bugs.

That would be great, let me know if I can help in any way. I have MKS Monster8 V1 and V2 motherboards with integrated CAN interface and MKS THR42 (CAN bus tool head). The MKS THR36 and MKS THR42 are electrically identical, only the form factor is different.

I managed to get the TMC2209 UART communication going on the THR42, it needs a low baud rate of 12K-32K, I recommend 22222 baud, which gives accurate timing numbers.
I needed to overwrite a weak function in SoftwareSerial to add "digitalWrite(RX_PIN, HIGH);"
(https://github.com/pkElectronics/SoftwareSerialM#master)

void TMC2208Stepper::preReadCommunication() { // Overwrite weak function
  #if SW_CAPABLE_PLATFORM
    if (SWSerial != nullptr)
    {
      SWSerial->listen();
    }
    else
  #endif

  if (HWSerial != nullptr)
  {
    if (sswitch != nullptr)
      sswitch->active();
  }
  
  digitalWrite(RX_PIN, HIGH);
}

Still in Marlin there seems to be a hardware conflict with the timers used by SoftwareSerial.
Here is the pins configuration I use, I'm not sure how to handle the onboard 16Mbit QUAD SPI flash memory.

// Servos
#define SERVO0_PIN                         11

// Limit Switches
#define X_STOP_PIN                         24
#define Y_STOP_PIN                         25
#define Z_STOP_PIN                         21

// Filament runout sensor
#define FIL_RUNOUT_PIN                     29

// Temperature Sensors
#define TEMP_0_PIN                         26 // Analog Input

// Heaters / Fans
#define HEATER_0_PIN                        0
#define FAN0_PIN                            1
#define FAN1_PIN                            2
#define FAN2_PIN                            3

// Misc. Functions
#define NEOPIXEL_PIN                       20

// E0 Stepper
#define E0_DIR_PIN                          4
#define E0_STEP_PIN                         5
#define E0_ENABLE_PIN                      10
//#define E0_CS_PIN                        10
#define E0_SERIAL_TX_PIN                    6
#define E0_SERIAL_RX_PIN     E0_SERIAL_TX_PIN
//#define E0_DIAG                           7

// Dummy defines, no X, Y and Z steppers
#define X_STEP_PIN                         -1
#define X_DIR_PIN                          -1
#define X_ENABLE_PIN                       -1
#define X_CS_PIN                           -1

#define Y_STEP_PIN                         -1
#define Y_DIR_PIN                          -1
#define Y_ENABLE_PIN                       -1
#define Y_CS_PIN                           -1

#define Z_STEP_PIN                         -1
#define Z_DIR_PIN                          -1
#define Z_ENABLE_PIN                       -1
#define Z_CS_PIN                           -1

#define TEMP_MCU  HAL_ADC_MCU_TEMP_DUMMY_PIN  // this is a flag value, don´t change

// No X, Y, Z stepper drivers are present
#ifndef X_SERIAL_TX_PIN
  #define X_SERIAL_TX_PIN                  -1
#endif
#ifndef X_SERIAL_RX_PIN
  #define X_SERIAL_RX_PIN                  -1
#endif

#ifndef Y_SERIAL_TX_PIN
  #define Y_SERIAL_TX_PIN                  -1
#endif
#ifndef Y_SERIAL_RX_PIN
  #define Y_SERIAL_RX_PIN                  -1
#endif

#ifndef Z_SERIAL_TX_PIN
  #define Z_SERIAL_TX_PIN                  -1
#endif
#ifndef Z_SERIAL_RX_PIN
  #define Z_SERIAL_RX_PIN                  -1
#endif

// QUAD SPI FLASH MEMORY ???????????
/*
#define HAS_SPI_FLASH                       1
#define SPI_DEVICE                          1
#define SPI_FLASH_SIZE              0x1000000 // 16Mbit
#define SPI_FLASH_CS_PIN              QSPI_SS // PIN56
#define SPI_FLASH_SD0_PIN            QSPI_SD0 // PIN53
#define SPI_FLASH_SD1_PIN            QSPI_SD1 // PIN55
#define SPI_FLASH_SD2_PIN            QSPI_SD2 // PIN54
#define SPI_FLASH_SD3_PIN            QSPI_SD3 // PIN51
#define SPI_FLASH_SCK_PIN            QSPI_SCK // PIN52
*/

[rondlh]

I managed to get the CAN bus working in Marlin between a MKS Monster8 (bxCAN, STM32F407) and a BTT EBB42 V1.2 (fdCAN, STM32G0). The code on the 2 platforms is quite different because of the different CAN support.
To enable CAN make sure to enable the build flags (HAL_CAN_MODULE_ENABLED for STM32F4, HAL_FDCAN_MODULE_ENABLED for STM32G0).
The current framework for STM32G0 does not officially support CAN, the CAN callbacks will not be called, so I made "void TIM16_IRQHandler(void)" weak in "framework-arduinoststm32\libraries\SrcWrapper\src\HardwareTimer.cpp" so I can override the function and call "HAL_FDCAN_IRQHandler(&hfdcan2)", which seems to be fully implemented.
I implemented a protocol that can transport gcode over CAN, one gcode command with 2 parameters (floats) can be packed into 1 CAN message. Commands with up to 16 parameters are supported.
With a little special attention the BLTouch and virtual remote IO (probe/endstops/filament sensor) also works fine, the Z-probe status is forwarded to the host, which is completely interrupt driven on both sides. (Interrupt feature on the toolhead triggers a CAN send, which is picked up by a CAN interrupt on the Monster8 side). I use 1M baud to make sure there is not too much delay. I keep the bus idle as much as possible. There is no need to update the host about the hotend temperature status too often, as the temperature is controlled by the toolhead anyway.
The one thing I didn't get under control is the E-stepper motor synchronization. Both board use inaccurate 8MHz crystals for clock generation, on the scope I can see that the EBB42 runs at about 99.7% clock speed compared to the Monster8. So just forwarding the gcode to the tool head causes issues very fast, adjusting the speed on the EBB42 improves the situation, but doesn't fully solve the issue. I guess I need to go a level lower and prevent timing errors to add up. So for now still use an additional stepper cable to the toolhead.

[jvishnefske]

Hi rondlh, I have not contributed to Marlin before, but i do have some experience writing for canbus. i ordered a BTT EBB42 V1.2 and the U2C. Does anyone know what the feasability would be to support adding CAN onto an existing controller by connecting a U2C CAN_OUT to a supported marlin controller USB?

[Grogyan]

The issue with using the USB on the control board is that, that port is often used by a host computer such as a Raspberry PI

Ideally, and it should be easier, to use hardware SPI instead of software SPI.

As for synchronization, this has been a core issue for a while, as Marlin needs to have a rewrite of the timing loop.
There are a few ways to do this, and I believe @thinkyhead is looking at using the same sync method as what RepRap firmware uses. The sync in Klipper is very different and not advisable to use with Marlin

[Grogyan]

The 8Mhz oscillator on these toolboards are generally use for a RTC, not for the CPU clock

So that shouldn't be an issue with timing errors that come up

[rondlh]

Hi rondlh, I have not contributed to Marlin before, but i do have some experience writing for canbus. i ordered a BTT EBB42 V1.2 and the U2C. Does anyone know what the feasability would be to support adding CAN onto an existing controller by connecting a U2C CAN_OUT to a supported marlin controller USB?

That sounds a bit complicated to me. I use a motherboard with CAN on board (MKS Monster V1 and V2), and directly talk to the BTT EBB42 V1.2 over CAN, which also runs Marlin. So the MKS motherboards is kind of a master that sends some commands to the EBB42 to control fans/BLTouch/heaters and such. The EBB42 in return sends the hotend temp back (I use 4 times a second) and the IO status if anything changes. This works very well, but I cannot get the EBB42 extruder stepper to synchronize reliably. If I send a long command to the extruder stepper then I can see that they start at the same time, but the commands do not finish at the same time. For now I use an additional stepper cable next to the CAN bus cable to solve this. Still not bad in my view.

[rondlh]

The issue with using the USB on the control board is that, that port is often used by a host computer such as a Raspberry PI

But you can use an USB hub I guess...

Ideally, and it should be easier, to use hardware SPI instead of software SPI.

SPI?

As for synchronization, this has been a core issue for a while, as Marlin needs to have a rewrite of the timing loop. There are a few ways to do this, and I believe @thinkyhead is looking at using the same sync method as what RepRap firmware uses. The sync in Klipper is very different and not advisable to use with Marlin

That seems right, I think a lower level control of the remote stepper is needed.

[rondlh]

The 8Mhz oscillator on these toolboards are generally use for a RTC, not for the CPU clock

So that shouldn't be an issue with timing errors that come up

The BTT EBB42 V1.2 runs at 64MHz, I'm not sure how this clock is generated, but what I can confirm is that there is a notable stepper clock difference (about 0.3% in my case).

[InsanityAutomation]

FYI there is an implementation here - https://github.com/markniu/PandaCAN/ - Personally ive kept away from any of the can implementations as none have brought in a clock sync. Its not a synchronous bus as many assume, and the output planning would need significant overhaul to execute blocks on a timing trigger.

[rondlh]

FYI there is an implementation here - https://github.com/markniu/PandaCAN/ - Personally ive kept away from any of the can implementations as none have brought in a clock sync. Its not a synchronous bus as many assume, and the output planning would need significant overhaul to execute blocks on a timing trigger.

I'm aware of this project, I used it for reference and inspiration. You can avoid the synchronization issues by just using the extruder stepper driver on the motherboard. This requires an additional toolhead cable, but the cable is an easily available standard cable, so no big issue for now in my view.

Other items work find like:

• X, Y, Z, probe endstops and filament detect signals (including BLTouch and 3DTouch)
• Cooling fan and auto hotend fan
• Hotend heater and thermistor reading (thermocople if needed)
• Tool head lights/neopixel etc.

The onboard accelerometer ADXL345 needs some work, and there even is an SPI bus if you need one.
TMC2209 stepper control and configuration also works fine, but I don't use the toolhead stepper driver.

[InsanityAutomation]

Endstops / probe you will lose accuracy due to communication dwell vs interrupt driven local IO however this is within application requirements provided you lower homing speed to compensate. Heater output will absolutely need some heavy thought on local safety. We dont want to recreate the same issues klipper has where pin states are left stale and heater blocks melt when it disconnects just the wrong way / time.

Regardless of design intent to limit motion on them... Ive seen people abuse toolboards for every axis on a machine... People find ways to do weird stuff lol

[rondlh]

Endstops / probe you will lose accuracy due to communication dwell vs interrupt driven local IO however this is within application requirements provided you lower homing speed to compensate.

My implementation is also interrupt driven, first on the toolhead, and also on the main motherboard that receives the CAN IO update. This results in a small but stable time delay of about 50uS (I run at 1M baud). As long as the delay is stable it doesn't impact accuracy. I keep the CAN bus idle as much as possible for this reason.

Heater output will absolutely need some heavy thought on local safety. We dont want to recreate the same issues klipper has where pin states are left stale and heater blocks melt when it disconnects just the wrong way / time.

No worries on this topic, because the toolhead is running Marlin too, which has thermal protection enabled, and if you want you can enable HOTEND_IDLE_TIMEOUT and implement a heart beat signal (I didn't implement that yet).

Regardless of design intent to limit motion on them... Ive seen people abuse toolboards for every axis on a machine... People find ways to do weird stuff lol

Right, the toolboard is a tiny and powerful board that offers lots of possibilities

[Grogyan]

Just wondering, how far you managed to progress on your implementation @rondlh?

[rondlh]

All tested and working well on the latest Marlin.
Probing is working very reliable, the only thing I didn't get working is the synchronization of the stepper on the toolhead (BTT EBB42 V1.2). To solve this I use the stepper on the motherboard and there is a stepper cable next to the CAN cable going to the toolhead. On all other topics I'm perfectly happy with this solution. I can post the projects (host + head) if anybody is interested.

[aurion55]

All tested and working well on the latest Marlin. Probing is working very reliable, the only thing I didn't get working is the synchronization of the stepper on the toolhead (BTT EBB42 V1.2). To solve this I use the stepper on the motherboard and there is a stepper cable next to the CAN cable going to the toolhead. On all other topics I'm perfectly happy with this solution. I can post the projects (host + head) if anybody is interested.

Please post the Host and Head setup? What board you're using?

[rondlh]

Please post the Host and Head setup? What board you're using?

What do you mean with "setup"? I'm using Marlin, not Klipper.
I use a MKS Monster8 V1/V2 with a BTT EBB42 V1.2

Both boards are running the latest Marlin betas. The CAN bus needs some customizations of course, and additionally I have quite a number of customizations for ESP32 and BTT TFT integration (custom ExtUI). Perhaps I can filter out all non-essential changes.

[aurion55]

Please post the Host and Head setup? What board you're using?

What do you mean with "setup"? I'm using Marlin, not Klipper. I use a MKS Monster8 V1/V2 with a BTT EBB42 V1.2

Both boards are running the latest Marlin betas. The CAN bus needs some customizations of course, and additionally I have quite a number of customizations for ESP32 and BTT TFT integration (custom ExtUI). Perhaps I can filter out all non-essential changes.

Thanks.

[oliof]

The issue with using the USB on the control board is that, that port is often used by a host computer such as a Raspberry PI

Ideally, and it should be easier, to use hardware SPI instead of software SPI.

There are hardware SPI modules to support CAN-FD on STM32F4 boards for RepRapFirmware (DFD to go into a stepstick driver slot, EFD to use the EXP expansion port), maybe those are worth looking at for enabling CAN on a wider range of boards. I believe @thinkyhead may have gotten one of these in the past.

[Duality4Y]

I like CAN very much,
I have worked a lot with CAN both normal ID's and Extended ID's

CAN is robust has many mechanisms build in for error checking, it is reasonably fast (depends on bitrate)
plus from a electrical viewpoint, it's differential signalling, so CAN has a high noise immunity.

It might be worth to think about device addressing and allocation, if everyone can set their own ID then it can become a mess real quickly.

Having a good ID allocation will benefit making a robust bus and will contribute to making it easy to use maybe even plug and play, if devices are allocated an ID which also identifies the TYPE of device it would make filtering CAN packets super easy, and then a controller could send a discover command and figure out what devices are connected.
It could see that new hot-ends are connected, new steppers, new probes, other things.

after this a command protocol has to be build to communicate with the TYPE of device, to request the capabilities of the device and sending telemetry or other data (that is heat or speed or z-offset or anything else)

Something to keep in mind:
to many devices will eat up bus time make responses slower, create synchronization issues etc.

[thinkyhead]

We're beginning to get some CAN bus features, so we can continue discussing specifics on those submissions as they arrive. Thanks for all your feedback on this most important feature!