Introducing: USBBUS

[Dave32]

USB expansion *at* the toolhead would be huge.
Almost anything you could dream of could be connected - and prototyping new ideas would be simpler as well.

Taken to the other extreme, are we now at a point where someone could make a functioning printer with just four USB-connected Nitehawk-SBs and a Raspberry Pi? No "control board" required?

 

[YAOG]

USB expansion *at* the toolhead would be huge.
Almost anything you could dream of could be connected - and prototyping new ideas would be simpler as well.

Taken to the other extreme, are we now at a point where someone could make a functioning printer with just four USB-connected Nitehawk-SBs and a Raspberry Pi? No "control board" required?

Yes, adding a USB hub or what is in effect a USB hub at the end of the Nitehawk's USB toolhead umbilical would be nice. It sure would make plugging in a device like the pre-packaged Beacon easier. I'm not sure if there is anything else that we could stuff on the toolhead that uses a standalone USB port. That said I'm struggling to imagine any new and useful devices that would need to live on the toolhead given the serious desire to keep the flying mass as low as possible for print speed and quality.

I don't think we are anywhere near your imagined control system but it is interesting to consider an even more extreme system. Imagine that we take every 3D printer function and localize control using cheap MCUs for every class of 3D printer device, motion, fan, current, sensor etc. these devices where topologically appropriate could be combined.

For example a dense toolboard which might include an accelerometer, bed probe, extruder stepper controller, optical filament movement detection, hot end, hot end cooling fan, part cooling fan, hot end thermistor, ambient thermistor, LEDs, blob/spaghetti camera. Or maybe a new category, the bedboard which might include center thermistor, edge thermistor, bed heat relay and environmental bed fans.

Then most everything could be modular and we would just spec the use of a high power USB spec and cable to connect to the main processor hub which could also inject the necessary current.

Steppers for toolhead or bed motion would have a board with an MCU and a stepper controller. And while I'm making my wishlist the controller would include a shaft encoder to detect motion issues and a stepper motor thermal probe etc. etc.

I don't know how far it would make sense to take these ideas but it's entertaining to think about. The question is, is there a need for this level of modularity and cost to gain simplicity and reliability.

 

[Dave32]

That said I'm struggling to imagine any new and useful devices that would need to live on the toolhead given the serious desire to keep the flying mass as low as possible for print speed and quality.

I'd say that's spot-on why the expansion is important. If we could envision it today, we would have provisioned for it yesterday. It's the stuff that is *new* for tomorrow that requires the expansion flexibility.

As an example, consider the ADXL345. They were I2C or SPI-connected devices with dedicated wiring and breakout boards on the Pi when they came out. Then some designers stepped it up and they became USB-C for easier connectivity. Now they are integrated directly onto the toolhead boards, with no special mounting, nothing to do on the Pi, and no special or extra wiring. That's the development lifecycle - prototype, refine, incorporate. Having USB expansion at the toolhead gives the perfect connectivity for rapid prototyping of all kinds of novel ideas - the good ones of which can then be incorporated directly if they prove beneficial.

 

[YAOG]

I'd say that's spot-on why the expansion is important. If we could envision it today, we would have provisioned for it yesterday. It's the stuff that is *new* for tomorrow that requires the expansion flexibility.

As an example, consider the ADXL345. They were I2C or SPI-connected devices with dedicated wiring and breakout boards on the Pi when they came out. Then some designers stepped it up and they became USB-C for easier connectivity. Now they are integrated directly onto the toolhead boards, with no special mounting, nothing to do on the Pi, and no special or extra wiring. That's the development lifecycle - prototype, refine, incorporate. Having USB expansion at the toolhead gives the perfect connectivity for rapid prototyping of all kinds of novel ideas - the good ones of which can then be incorporated directly if they prove beneficial.

BTW, the LDO Night Hawk toolboard uses the RP2040 MCU which I think is about $0.80 each at retail. So the cost for a local MCU controller and the related support chips for virtually anything should be pretty cheap. The high current USB cables will cost more than a populated PCB.

 

[Yaaj]

Had a similar idea for the 2.4 I just completed. But stopped because of the Nitehawk. And watched the two Nero videos...
On the Stealthburner, the CAN interface is a EBB36. I'd like to add a nozzle cam (but not sure I will do it after Nero answered a question in his last video about the Nitehawk...) ; I'd also like a camera attached to the gantry, not to the frame.
Also wanted to use the USB interface instead of CANBUS. Did some testing, was working fine. Also, I didn't want a umbilical, and installed a horizontal dragchain. Unfortunately, the only 7x7mm open dragchain I could find are available from Bambu Labs (for cheap), and Bambu parts have nothing to do on a Voron. [EDIT] USB C to USB C toolhead cables are available from Bambu Labs...
Finally did this : got a closed 7x7 drag chain, installed a homemade CAN cable (twisted according to specs, made from the remaining LDO wiring), and crimped the connectors. Meaning the cable is captive. Routed a low profile USB cable from the Pi to the gantry, and installed the U2C on the gantry. My build is a bit special : the electronics is in a drawer, and all wiring routed in long drag chains : from the Pi to the gantry : 1.2 meter. The USB cable is side by side with the motors, no problems so far. Don't forget USB on toolhead microcontrollers is the slowest (1.1, 12MBps !)

Was looking for USB hub modules. Found those I completely forgot about. (I have one in my desktop PC) :


Easily hackable, a bit bulky but lightweight ; USB 2.0 high speed, 1 port to 4 ports. Cheap. Based on a chinese IC with 6 caps and a quartz. 2.54mm HE connectors that can easily be replaced with something else (smaller JST for example) ; even point to point soldered wires.

Such a module could be installed on a toolhead. The schematics is so simple that a custom PCB is very easy to design, and the IC is ubiquitous (SL2.1A)

Datasheet - LCSC Electronics

LCSC Electronics is a global components distributor with a wider selection in stock. Choose us for all your component needs - where quality, selection, and honest prices can be offered.

datasheet.lcsc.com

Can be found on Amazon, eBay, Ali, Bangood, etc. Could even unsolder the components and reuse them. (0805 and 1206) ; 100µF caps could be replaced with smaller footprint ones.





Impedance matched connections are overkill. No need for special cables for a few centimeters, the toolhead USB being very low speed. STM32F103 : 12 Mbps, RP2040 : 12 Mbps too (USB high speed 1.1)

For now stuck because of the availability of the Nitehawk

For now, have to stick to the hybrid solution : PI -> USB -> Gantry -> U2C -> CANBUS -> Toolhead. Still didn't test the hub with both a cam and the toolhead. Next project after the printer is calibrrated.

 

[ChrisA]

i ran this board on my v0 for a quite some time and it was great, it does exactly what you said in combining the 24v/GND with the USB signal wires with a small breakout board i really liked it. made flashing, updating really easy. i wish more CAN boards would enable this option using dip switches or something along those lines so you COULD run it as USB or CAN depending on what you want.
The way you have setup with the 6 conductor cable on yours seems to be a decent idea as well with the little USB breakout plugged in

This could work, but the design ignore the USB standards. Let's hope ad-hoc USB-like solutions do not become mainstream in the 3D pprinrter community.

The danger is that if you use a USB connector but don't follow the rules some one will try and connect a real USB device and then smoke happens. Yes "smoke." In a real USB system the two devices at each end of the cable "talk" to each other before putting more then 500 milliamps into the USB cable.

If you do it right it is possible to send more than 200 watts down the wire. After all, many notebook computers use USB cables for charging. We expect to be able to connect anything if the plug fits and not have to read a user manual first. I have a bunch of USB-C connectors on the back of my computer and I can connect amouse of a 27" monitor and it "just works"

USB is the ideal cable type for a 3d printhead. it can send quite a lot of power at 24 votes and it is very fast, gigabits if you need that. USB also has an Isocchronus mode where frames move at a fixed specified rate

Also you don't need any new software. Klipper already know how to take to an MCU over USB.

In summary, the USB idea is very good, as long as it is not "USB-like" but actually real USB.

 

[YAOG]

This could work, but the design ignore the USB standards. Let's hope ad-hoc USB-like solutions do not become mainstream in the 3D pprinrter community.

The danger is that if you use a USB connector but don't follow the rules some one will try and connect a real USB device and then smoke happens. Yes "smoke." In a real USB system the two devices at each end of the cable "talk" to each other before putting more then 500 milliamps into the USB cable.

If you do it right it is possible to send more than 200 watts down the wire. After all, many notebook computers use USB cables for charging. We expect to be able to connect anything if the plug fits and not have to read a user manual first. I have a bunch of USB-C connectors on the back of my computer and I can connect amouse of a 27" monitor and it "just works"

USB is the ideal cable type for a 3d printhead. it can send quite a lot of power at 24 votes and it is very fast, gigabits if you need that. USB also has an Isocchronus mode where frames move at a fixed specified rate

Also you don't need any new software. Klipper already know how to take to an MCU over USB.

In summary, the USB idea is very good, as long as it is not "USB-like" but actually real USB.

AFAIK the Nighthawk is as you say "real" USB but with a couple differences. The first issue is Nitehawk uses convenient but not USB standard connectors on both ends of the Nitehawk umbilical cord and what is normally 5 volt VCC is instead 24 volts. But as far as the USB port on the PC or R-Pi is concerned its just another day in USB land because the USB/power adapter PCB output is straight up USB Type-A.

As I understand it the Beacon is similar, proprietary connector at the PCB with a standard USB Type-A on the other end. This works fine for me as I am not worried that anyone playing in this sandbox will not tread with care.

 

[Dave32]

USB data + 24V power on non-standard cables/connectors is completely workable. All it would take is a 5V regulator at the downstream end, and you could return to a "normal" USB 2.0 connector (with or without a local USB hub) without any issues for downstream devices. No non-standard USB needs to be run on "standard" USB cables, and there is no need for any high-power modes that require hardware/software negotiation.

USB 3.0 and beyond, especially with the Type C connector, would be rapidly diminishing returns. If the toolhead doesn't need the bandwidth, then all of the extra data pairs and support chips just add weight, complexity, and failure points.

 

[YAOG]

USB data + 24V power on non-standard cables/connectors is completely workable. All it would take is a 5V regulator at the downstream end, and you could return to a "normal" USB 2.0 connector (with or without a local USB hub) without any issues for downstream devices. No non-standard USB needs to be run on "standard" USB cables, and there is no need for any high-power modes that require hardware/software negotiation.

USB 3.0 and beyond, especially with the Type C connector, would be rapidly diminishing returns. If the toolhead doesn't need the bandwidth, then all of the extra data pairs and support chips just add weight, complexity, and failure points.

Which is exactly why Nitehawk makes an awful lot of sense. When CANBUS first popped up it made sense to adapt it but with the USB option I see no good reason to go CANBUS today and the Nitehawk kit costs are very reasonable given what is in the box. Sure, it might take another iteration before the potential issues of the circuit are found but in the end USB on the toolboard makes a lot more sense for those running Mainsail on R-Pi. Who knows, maybe my crazy idea of building USB tool boards, build plate boards and stepper boards is not to far from reasonable.

 

[MichaelOToole]

It's entirely possible to work without cables be they USB or CANBUS... just use WiFi.

Consider a small PCB consisting of ESP32, 2209 and some basic control/regulation and you could remote all aspects of a 3D printer...
A Pi or similar could control as many motors, hotends, sensors etc., as required.

I just thinking out loud...

 

[YAOG]

It's entirely possible to work without cables be they USB or CANBUS... just use WiFi.

Consider a small PCB consisting of ESP32, 2209 and some basic control/regulation and you could remote all aspects of a 3D printer...
A Pi or similar could control as many motors, hotends, sensors etc., as required.

I just thinking out loud...

Unfortunately you still need a power connection at each device.