2024 : R.I.P. CANBUS !

[YaaJ]

https://docs.ldomotors.com/en/voron/nitehawk-sb

https://www.fabreeko.com/products/nitehawk-sb-toolhead-by-ldo

Hope it will not take too long before it's available in the EU, and/or BTT anounce something similar...

Can't wait !

[mvdveer]

You made me order them!!!! Gonna tell my wife it was @YaaJ that tempted me into buying it. 

All of the taemfdm family knows my weakness. Show him something new - he will buy and try.  Yes I already pre-ordered when I first became aware of these.

Thanks for sharing this. Will be much easier than canbus. Maybe now we will get @claudermilk on board to change the mass of wires (18 I think he said) in his cable chain to just a few 

Wonder how the raspi's will cope with all the USB devices. (Camera's, Beacon/IDM, Toolhead board, etc). I had the occasional "mcu disconnected" on the VZBot during long prints but has put that down to the Raspi overheating and throttling.

 

[YaaJ]

7 hours ago, mvdveer said:

Wonder how the raspi's will cope with all the USB devices

This is a real question ! I too wonder. Maybe some sort of priority ?

The RP2040 datasheet says USB up to 12 Mbps (full speed). It is nothing compared to the Pi USB 2.0 (480 Mbps, high speed), and the microprocessor speed (in the GHz range : 2 orders of magnitude).
Same with the STM32's (12 Mbps, full speed)

12 Mbps is more than enough. A toolhead works fine with 250 kbps. From the Klipper forum, motors + accelerometer could require up to 1 Mbps. Critical parts of Klipper running on the Pi are coded with C.

This being said, the Bambu printers have been USB fueled for a little while... Unless it is just a repurposed USB cable, but not USB protocol ?

The sad thing is that there is no hub on the PCB : no Beacon probe, no nozzle cam...

Had a look to the required bandwidth for cameras. Had no idea. They are bandwith hogs !

https://www.cctvcalculator.net/en/calculations/bandwidth-calculator/

Maybe time to use WiFi cams ?

 

[Calvinx]

Anyone who thinks that "proper" canbus (as in Can FD) is inferior to the product being discussed is sadly very uninformed..

It does however appear (on paper at least) to be superior to the current klipper canbus offerings which are worse than skata

[YaaJ]

Not inferior or superior. Just much simpler for the end user as the toolhead controller is seen as another mainboard.

CANBUS requiring a USB to CAN adapter, standalone or CAN capable mainboard, in the end it still is USB, as the Raspberry has no native CAN interface.
Most printers use USB or UART between their Pi and the mainboard. What does CAN add for just the toolhead, compared to USB C and its 200W ?

CANBUS would be much more usefull if we could chain all printer devices (motors and sensors). Is CAN FD bandwidth enough to do it ? (it seems it is)

We'd save a lot of wiring. For now, it is for umbilicals only (OK, some use additional EBB or similar controllers for other purposes : smart but not common)

[Calvinx]

As I said, a proper canbus system,  is as simple as it gets, the offering from Duet is Four wires already has firmware installed, its plug'n'play and boots in around 5 seconds. klipper only "acts" like its the best....

 

I should edit to add i run klipper on Duet-3 mainboard (and the 1LC) toolboard too so im not a RRF fan boy but Duet hardware is superior The failing for me is the Clunky Nature of the Duet Web Control looks terrible and running Klipper allows me to use Fluidd

Edited January 25 by Calvinx
updated info

[claudermilk]

 I knew once @mvdveer heard about this he'd have to give it a try. Yes, I am intrigued by this as an alternative to the clunky CANbus setups available so far. I expect that since it's LDO behind it, it will work well in the end.

However, I've getting an underpants gnome vibe off the wiring diagram. Writing up a snarky list of connections it hit me; none of the tool head components (fans, leds, heaters) get an actual physical connection to the controller board any more, do they? The additional 2040 processor connected to the Pi via USB handles that now, and the Pi gets the instructions to pass on via its connection (USB or UART/GPIO) to the controller. Right? If that's the case and software setup is as straightforward as LDOs docs look my interest level is high.

Oh, and my chain is currently 16 wires. It's about 2/3 of the basic spec bundle. 

[JohnGalt1717]

Too bad they didn’t use USB-PD then you’d only need the USB cable…

[Penatr8tor]

Looks interesting... I'm interested. 

[mvdveer]

On 1/26/2024 at 12:56 AM, Calvinx said:

Anyone who thinks that "proper" canbus (as in Can FD) is inferior to the product being discussed is sadly very uninformed..

It does however appear (on paper at least) to be superior to the current klipper canbus offerings which are worse than skata

I don't think it is a question of superiority, but more of another choice for those not keen to take leap to canbus. There is no denying that it sounds easier to setup. The reason I ordered one, is to compare setup between canbus and this latest product.

BTW: I have converted all my large printers to canbus and VERY happy with them. Occasionally running into lost communication issue on the Trident 300mm build running klippain - don't know if this is the problem. Have not had the inclination to check yet, as it occures infrequently.

[YaaJ]

On 1/26/2024 at 12:00 AM, JohnGalt1717 said:

Too bad they didn’t use USB-PD then you’d only need the USB cable…

I too was thinking this. LDO had to produce a cable that can be adapted to any printer...
The LDO approach allows us to crimp cables at the required length, and push the currents and voltages we need without another hardware/software layer. They have to think mass production.
Radio frequencies EE will argue that the connectors will not be impedance matched, and don't comply the USB specs. This is theory.
A printer toolhead will never be connected to a phone charger.
Simpler is better. Even if having a umbilical with two molded USB connectors would have be a dream (Bambu did it). But how much would cost cables with various lenghtes ? Do we really need cables with microcontrollers embeded in the connectors ?

[TitusADuxass]

I am still trying to work out what this "update" brings to the party.

[YaaJ]

- removes two USB/CAN adapters from the signal path (SN65HVDxxxx on the U2C and the EBB)
- bandwidth : 48Mbps instead of 1Mbps
- adapter : passive instead of active
- easier firmware updates
- no need for Katapult
- no need for Linux CAN network and drivers on the Pi
- cheaper : from Fabreeko : total -10 € compared to EBB36 + U2C and no cable ; no need for a RJ11 crimper or adapter plug (Octopus) ; comes with the umbilical cable unlike the other solutions
- fan headers with tacho signal (3pin)
- chamber thermistor

-> simpler, faster, more features, and cheaper !

[TitusADuxass]

I have only one USB/CAN (EBB36)

Bandwidth - mine's been working okay so far, so I don't know want the advantage of a higher bandwidth is.

Adapter - I've CAN capable mainboards.

Firmware updates are easily done with Katapult (okay, you have to get to know how to to do it much like the intial install)

Fan headers with tacho signal - why are they needed (honest question).

Chamber thermistor - surely this would be a toolhead thermistor.

 

[YaaJ]

Tach signal : https://ellis3dp.com/Print-Tuning-Guide/articles/useful_macros/hotend_fan_monitoring.html (I had this problem one time)
The EBB36 having two temp sensor inputs (one for a thermistor, and one on the MAX31865 amplifier for PT100/1000), we can add a second temp probe. Thermistor on the analog input (PA3), and MAX31865 input (communicates with the STM32 via I²C)

 

Edited January 29 by YaaJ

[ChicagoKeri]

13 hours ago, TitusADuxass said:

I have only one USB/CAN (EBB36)

Bandwidth - mine's been working okay so far, so I don't know want the advantage of a higher bandwidth is.

Adapter - I've CAN capable mainboards.

Firmware updates are easily done with Katapult (okay, you have to get to know how to to do it much like the intial install)

Fan headers with tacho signal - why are they needed (honest question).

Chamber thermistor - surely this would be a toolhead thermistor.

 

A fan header with 3 or 4 wires is a good thing, especially for the Hotend fan.  It would be nice to have the Hotend heater shut off if the Hotend Fan were to fail or get jammed with errant spaghetti.  In addition to reducing overheat risk, it could reduce the annoyance of extreme heat creep and cleaning out a lot of stuck filament.  Some CAN toolhead boards have this available, notably the BTT SB22009 / SB2240 boards. 

A dedicated Chamber thermistor would be an obvious easy addition for a CAN toolhead. Unfortunately, not all of them have one! 

[TitusADuxass]

17 hours ago, YaaJ said:

Tach signal : https://ellis3dp.com/Print-Tuning-Guide/articles/useful_macros/hotend_fan_monitoring.html (I had this problem one time)
The EBB36 having two temp sensor inputs (one for a thermistor, and one on the MAX31865 amplifier for PT100/1000), we can add a second temp probe. Thermistor on the analog input (PA3), and MAX31865 input (communicates with the STM32 via I²C)

That's something I will adopt. if Ellis has taken time to write about it, it must considered.

[YaaJ]

16 hours ago, ChicagoKeri said:

Chamber thermistor would be an obvious easy addition

Not an addition. It's already there. Just add the sensor, the pinheader is on the PCB ; tested with a bare tiny PT1000, no 4-wire (Kelvin mode) required. Cheap an easy. Can be as simple as unsoldering the pinheader and replace it with the sensor. Or as complicated as routing 4 wires to the cooler intake on a modded toolhead.
Or the opposite. PT100/1000 on the heater block, and chamber thermsistor.

11 hours ago, TitusADuxass said:

That's something I will adopt. if Ellis has taken time to write about it, it must considered.

20+ years all PCs have 4-pin fans on the CPU cooler. But general purpose 4-wire fans are not that easy to source. Most of them are 12V. 

[YaaJ]

Nero got a Nitehawk (jump to 1H40) :

 

 

Edited February 6 by YaaJ