Marlin icon indicating copy to clipboard operation
Marlin copied to clipboard

[FR] CAN bus

Open Grogyan opened this issue 8 years ago • 65 comments

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.

Grogyan avatar Sep 25 '17 05:09 Grogyan

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.

bobc avatar Sep 26 '17 10:09 bobc

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.

Grogyan avatar Sep 28 '17 01:09 Grogyan

Some projects for can controlled closed loop steppers already exist.

alexxy avatar Feb 14 '18 10:02 alexxy

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

tampas avatar Feb 20 '18 11:02 tampas

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

alexxy avatar Nov 12 '18 22:11 alexxy

It is based on CAN FB by the looks of it.

Still waiting for some CAN bus firmware support

Grogyan avatar Nov 13 '18 00:11 Grogyan

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

Blaster1920 avatar Feb 02 '19 10:02 Blaster1920

Is CAN or RS485 already supported by Marlin?

TVAVAE avatar Aug 29 '19 21:08 TVAVAE

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.

Grogyan avatar Aug 29 '19 21:08 Grogyan

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

TVAVAE avatar Aug 29 '19 21:08 TVAVAE

Best to go for CAN then.

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

Grogyan avatar Aug 29 '19 21:08 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

Grogyan avatar Aug 29 '19 21:08 Grogyan

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

alexxy avatar Oct 23 '19 13:10 alexxy

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.

Grogyan avatar Dec 02 '19 21:12 Grogyan

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

geraldjust avatar Dec 13 '19 06:12 geraldjust

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

Grogyan avatar Dec 18 '20 23:12 Grogyan

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 avatar Dec 19 '20 04:12 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.

Atanasovgoran avatar Dec 19 '20 04:12 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.

geraldjust avatar Dec 20 '20 01:12 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.

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.

Atanasovgoran avatar Dec 27 '20 07:12 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)

Grogyan avatar Dec 27 '20 22:12 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)

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

Atanasovgoran avatar Dec 27 '20 22:12 Atanasovgoran

"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

Grogyan avatar Dec 27 '20 22:12 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, [email protected] 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 .

Blaster1920 avatar Dec 27 '20 22:12 Blaster1920

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 avatar Dec 27 '20 22:12 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

Grogyan avatar Dec 27 '20 22:12 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

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.

Blaster1920 avatar Dec 27 '20 22:12 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.

sjasonsmith avatar Dec 27 '20 23:12 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.

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

Blaster1920 avatar Dec 27 '20 23:12 Blaster1920

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.

sjasonsmith avatar Dec 27 '20 23:12 sjasonsmith