[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, notifications@github.com 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 https://github.com/MarlinFirmware/Marlin/issues/7735#issuecomment-751524379, 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

[Grogyan]

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 .

Of course, CAN-FD is the new standard, and is used in the Duet V3. So it is best to use CAN-FD. Just casually speaking, I just refer to this as CAN Bus

[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 .

Of course, CAN-FD is the new standard, and is used in the Duet V3. So it is best to use CAN-FD. Just casually speaking, I just refer to this as CAN Bus

That's great. Should we just create a Discord or Telegram server where we can discuss about this while keep posting progresses on this issue page? I could happily give an hand with dedicated electronics.

[sjasonsmith]

While CAN FD brings performance improvements, it is only going to be available on a small number of control boards and would complicate making simple AVR-based CAN devices to attach to the board. In a closed eco-system that would be fine, but would make it much harder to adopt CAN across a wide range of devices.

Take STM32, for instance. Virtually every STM32 MCU has a CAN 2.0b controller, but to get CAN FD you have to go up to their STM32G/H/L lines.

The BTT GTR already exposes the CAN 2.0b pins from its STM32F4 controller, but you would still have to add transceivers to it.

[Blaster1920]

While CAN FD brings performance improvements, it is only going to be available on a small number of control boards and would complicate making simple AVR-based CAN devices to attach to the board. In a closed eco-system that would be fine, but would make it much harder to adopt CAN across a wide range of devices.

Take STM32, for instance. Virtually every STM32 MCU has a CAN 2.0b controller, but to get CAN FD you have to go up to their STM32G/H/L lines.

The BTT GTR already exposes the CAN 2.0b pins from its STM32F4 controller, but you would still have to add transceivers to it.

I don't think it's going to be a massive problem to create a custom board that communicates to the main board via SPI, given that that's how the can controllers communicate back to the MCU usually. I don't think avr boards are that interesting anymore, especially if no communication busses are exposed and free (SPI/uart) Also it's clear that this implementation is gonna be a bet, if it works it'll probably be implemented more by BTT and other electronics companies, otherwise... We tried at least :D Discord server, feel free to join: https://discord.gg/RSDtRTKSt5

[sjasonsmith]

I don't think it's going to be a massive problem to create a custom board that communicates to the main board via SPI, given that that's how the can controllers communicate back to the MCU usually.

It would seem more beneficial to leverage the built-in CAN controllers in modern MCUs. You are likely going to get much better performance that way.

I don't think avr boards are that interesting anymore

I was thinking more on the peripheral end rather than for the control board. It is pretty trivial to implement a small CAN peripheral using something like an ATTiny, a cheap SPI/CAN interface and a sensor.

[Grogyan]

I don't think it's going to be a massive problem to create a custom board that communicates to the main board via SPI, given that that's how the can controllers communicate back to the MCU usually.

It would seem more beneficial to leverage the built-in CAN controllers in modern MCUs. You are likely going to get much better performance that way.

Ideally using the CAN controller on modern microcontrollers, is preferable, myself I have the super cheap SKR 1.4. So I figure that having a separate controller that ties into the I2C or hardware SPI to translate to CAN could work.

[sjasonsmith]

It looks like the SKR 1.4's TMC SPI pins align with LPC1768 pins that can be mapped to the RD2/TD2 needed for the CAN2 peripheral. You would of course have to figure out how to expose the CAN functionality to Marlin.

[Atanasovgoran]

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

Well, yes, USB-C has 2 USB 3.0 twisted pairs and 1 for the USB 2.0. I am not sure about the communication lines. Anyways. I guess I will start the repo tomorrow after work and invite you over.

[geraldjust]

Ok here is my take, i good way to start would be to create "heads bowden style", This would be the following: -mosfet (for heater, mosfet (for fan 2 fans, ) temp in. So to make this will be very simple. we can have the PID controls on a MCU on the head handle the temp read, and maybe even add a TMC2209 for a stepper control. This is the easiest to Start experimenting with. As the only thing needed is to pass the target temp to can bus and have the "head board" read it and turn it on, do its thing and report back the temp of the head.

Ive heard alot of can 2.0B vs FD, but to be honest FD is not as supported in ICs currently as 2.0. For canbus to be viable it need to be cost effective. One of the few ways to this is to is to use IC that have built in support. But do note even if the IC has a built in canbus controller, 99% of them will still need a external transceiver. As for wires, You only need 4 in total, 12/24/36v , CANH, CANL, GND. LDO regulators can be on board, This helps with future proofing or mix matching 3.3v logic and 5v logic of different boards. I can build and setup a simple board if anyone is really interested in this. Lastly and the most important.. A standardization "table" would be needed. So for example.. ID 0x200 =. first head, ID, 0x210 second head etc... setup what should be priority.

Edit: the biggest challenge is just to support canbus, and how to shift certain data or functions to be enabled via can. Or having a abstract layer at least for the data.

[Atanasovgoran]

Ok here is my take, i good way to start would be to create "heads bowden style", This would be the following: -mosfet (for heater, mosfet (for fan 2 fans, ) temp in. So to make this will be very simple. we can have the PID controls on a MCU on the head handle the temp read, and maybe even add a TMC2209 for a stepper control. This is the easiest to Start experimenting with. As the only thing needed is to pass the target temp to can bus and have the "head board" read it and turn it on, do its thing and report back the temp of the head.

Ive heard alot of can 2.0B vs FD, but to be honest FD is not as supported in ICs currently as 2.0. For canbus to be viable it need to be cost effective. One of the few ways to this is to is to use IC that have built in support. But do note even if the IC has a built in canbus controller, 99% of them will still need a external transceiver. As for wires, You only need 4 in total, 12/24/36v , CANH, CANL, GND. LDO regulators can be on board, This helps with future proofing or mix matching 3.3v logic and 5v logic of different boards. I can build and setup a simple board if anyone is really interested in this. Lastly and the most important.. A standardization "table" would be needed. So for example.. ID 0x200 =. first head, ID, 0x210 second head etc... setup what should be priority.

Edit: the biggest challenge is just to support canbus, and how to shift certain data or functions to be enabled via can. Or having a abstract layer at least for the data.

Join the discord we are making progress with a dev board. We have selected to go with MCP2518FD and MCP2542WFD. We where thinking of implementing CAN bus peripherals as "virtual" pins since Marlin 2.0 uses a hardware obfuscation layer it might work.

[alexxy]

@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)

Its better to have 4 wires: 2 for CAN data 2 for high power (and get 3.3 of 5v from dc-dc onboard)

Actualy i'm going to order few stm32g4 boards (my design of pcb, with wide Vin, and CAN-FD (so it will be compatible with CAN2.0b). I plan to use them to create stepper with closed loop, heater with thermistor or thermocouple and other printer parts. So it will be possible to create a printer that uses CAN bus as main bus, with distribute electronics (so also CAN connected display, MMU2 with can and other units).

[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)

Its better to have 4 wires: 2 for CAN data 2 for high power (and get 3.3 of 5v from dc-dc onboard)

Actualy i'm going to order few stm32g4 boards (my design of pcb, with wide Vin, and CAN-FD (so it will be compatible with CAN2.0b). I plan to use them to create stepper with closed loop, heater with thermistor or thermocouple and other printer parts. So it will be possible to create a printer that uses CAN bus as main bus, with distribute electronics (so also CAN connected display, MMU2 with can and other units).

Please join the discord. We all seem to work separately and not moving forward...

[alexxy]

What channel?

[Blaster1920]

What channel?

Anyone. After joining the server you can discuss in the appropriate channel.

[alexxy]

What channel?

Anyone. After joining the server you can discuss in the appropriate channel.

I already use discord. And have access to marlin dev-team

[Grogyan]

Have ordered a CAN bus extruder module, though at this stage no idea how to code marlin to get it to work

[FL140]

Is there any news on this? I couldn't find to much information on this in the Discord dev-talk channel (Besides searching information on Discord is like a paper chase.)

Asking because there are a couple of CAN modules for 3D printers out now which look great (e.g. BTT EBB36/42 v1.2, Fly-SHT36 v2.2, Fly-SB2040). Those are already supported by Klipper. It would be great to see support for CAN in Marlin.

[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