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)

CoreChips SL2.1A Datasheet

SL2.1A CoreChips $0.2399 - Hub SOP-16 USB Converters ROHS datasheet, price, inventory C192893

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

 

[eselcuker]

When I first got ebb36 and didn't have u2c I thought of something like this but in a different way,

My project was more complex, cutting (from the solders) the H and L pins of the female can bus port on the EBB 36 from the inside and soldering the data+ and data- pins of the USB C connector to the cuted pins of the microfit connector. In this way, you can make a more original and quality cable by connecting only the microfit connector to EBB 36. At the other end of the cable, you can connect a USB socket with only data+ and data- pins connected to pi and the power cables directly to the power supply. When using it with a usb c cable, sometimes the connection would drop during printing due to vibration (maybe because of my bad cable). Type C cables lose their power to hold the socket after a while and cause connection problems.

If you are still working on this project you might consider this. 6th and 7th pins of the USB c port (soldered side) data + and data -

sorry for my bad english,

 

[Maddog]

I installed the Cartographer3D instead of the beacon because Cartographer3D supports CAN or USB. The TAP option is a bad idea. The hotend should never touch the bed on purpose.
Cartographer3D works great on CAN. No need to add another USB cable to the toolhead.
I think the only option the toolhead guys could make is add a simple 4 pin JST cable connector for this additional CAN bus since it does not move like the cable connecting to the master controller.
CAN does not require a hub like the USB. There are plenty of reasons to use CAN over USB. With CAN already available why push back to USB?

 

[MichaelOToole]

Over the past five months I've had several print failures due to CANBus communication errors. This was partially solved by rerouting one motor cable and re-crimping a connector I suspected had issues, since then I have only had one CANBus comms error but still, this is not ideal...

I may try the USB solution as I have the required parts, basically, all communication methods are subject to the same potential problems...

As for TAP, although it's not perfect as you need ensure the heater is below 150° C before probing (to prevent damage to the bed), but it can reduce damage to the heater and bed should they collide which in itself might warrant its inclusion.

Also, TAP doesn't remove the need for probe calibration which perplexes me...

 

[Maddog]

USB cables are not designed to bend thousands of times per print.
CAN is designed for high noise worlds. The cables are designed for a hostile world.
I have had CAN running for some time and not had any comm errors.

 

[MichaelOToole]

You don't use a standard USB cable for this application, check out Nikehawk SB USB cable designed for the application...

 

[469]

While to reduce the number of wires as much as possible, you would use only usbc data and combine the grounds, is it possible to use a normal, off the shelf usbc cable alongside the 24v input on the 4 pin?

 

[MichaelOToole]

Requirements:
A 60 Watt heater powered by 24V will draw 2.5 Amps, motor about 1 to 2 Amps... total 4.5 Amps
A 80 Watt heater powered by 24V will draw 3.4 Amps, motor about 1 to 2 Amps... total 5.4 Amps

In theory a quality USB-C cable operating at 24V can safely deliver 5 Amps, so it might be possible to use a USB-C, but only with the right heater and motor...
The length of the cable will play a part but no mention of this on the pages I visited, best assume 1 meter to be on the safe side. In reality we need a cable a little longer than 1 meter...

My Test Setup:

1. Get a USB-C cable and cut off the connectors, fit new connectors...
2. Connect to a 24 volt source and load set for 5.5 Amps...
3. Measures temperature of cable and connectors...
4. Wait a period of time (say 10 minutes), the check temperatures again...

If the temperature remains constant, it's probably fine to proceed...
If there's a marked temperature rise in either the cable or connectors... probably not but!

After cutting off the connectors, you will have spare cables, if we reused these cables to optimize for current and possibly voltage too, that should work...

 

[Maddog]

I think most of this discussion is now moot "at this point" since a few Voron toolhead board vendors now support CAN or USB on the same connector.
Keep in mind the CAR industry is moving away from CAN back to Ethernet not USB. They see USB as a poor fit. I would think that should be a consideration here.

This board below (example, not an endorsement) also includes most everything you would want on a toolhead including the "Beacon" scanning probe without the high cost of Beacon.
It has the CAN expansion connector, CAN termination. With CAN built-in hardware priority support it is a very good 3D printer fit.
This board does not have support for USB toolhead CAM. Not sure that has a large need as it impacts the toolhead weight.
This board can be purchased today for less than the Beacon cost alone. Beacon $65, Nitehawk $40 on sale, Fly-SB2040 $35. BTT-SB2209 $30.
Personally I think Beacon and Nitehawk will be out of business in a year. FLY (Mellow) and BTT will crush them with their high integration and price advantage.
That's just my prediction.

Fly-SB2040 Max V3​

​

 

[YAOG]

I think most of this discussion is now moot "at this point" since a few Voron toolhead board vendors now support CAN or USB on the same connector.
Keep in mind the CAR industry is moving away from CAN back to Ethernet not USB. They see USB as a poor fit. I would think that should be a consideration here.

This board below (example, not an endorsement) also includes most everything you would want on a toolhead including the "Beacon" scanning probe without the high cost of Beacon.
It has the CAN expansion connector, CAN termination. With CAN built-in hardware priority support it is a very good 3D printer fit.
This board does not have support for USB toolhead CAM. Not sure that has a large need as it impacts the toolhead weight.
This board can be purchased today for less than the Beacon cost alone. Beacon $65, Nitehawk $40 on sale, Fly-SB2040 $35. BTT-SB2209 $30.
Personally I think Beacon and Nitehawk will be out of business in a year. FLY (Mellow) and BTT will crush them with their high integration and price advantage.
That's just my prediction.

Fly-SB2040 Max V3​

View attachment 5050

​

This is not the auto industry. This is a computer / technical hobby and the USB standard is ubiquitous and not going anywhere any time soon. There is way more to this than just being a few bucks cheaper and very often cheaper circles back to bite the buyer in the butt and ends up costing more than just money - lost time, frustration and wasted materials come to mind.

I usually recommend buying well designed and built quality gear over price and I don't think I'm alone, If I was there would be no LDO. Keep up the predictions, it is always entertaining to see what happens IRL and the marketplace.