What's new
VORON Design

Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members!

Introducing: USBBUS

kubik

Active member
Hi,

I am sure that by now, you have most probably heard about the venerable CANBUS. Less wires, umbilicals galore; but more headaches with yet another thing to learn. Wouldn't it be great if you could get similar benefits without all of the hassle? Well, do I have a thing for you! But first, let me explain how we got here.


From what I gather, CAN has sprung up in our circles as it *theoretically* fits the bill. Since CAN is a bus architecture, you should be able to run a single cable (the bus) and hook devices up to it. Practically, it is my belief, this promise has not fully materialised. Here are a few reasons why I think it is so:

- there are no T connectors available (TODO: footnote about bulky car ones no one uses)
- virtually all of the boards are designed as terminal nodes, i.e. you do not have a second connector to continue the bus going further along
- basically everyone who setups CAN does so to be able to run a single thing -- the toolhead board.


The last point is my main gripe with the way we in the community use CAN currently. That's why I would like to introduce another option --- USB.


There are a few quite nice advantages to using USB, namely:
- the majority of the people already have it AND know how to use it. Virtually all of the boards that we use in our printers are connected either via native USB or USB-to-serial
- connected to the previous point, there is no particular setup required, it is PnP (Plug & Play).
- another connected point - cheaper because we do not need another board, we probably have spare USB ports.
- it brings the same major advantage that people like about CAN --- only 4 wires are required


Before naming the disadvantages, I would like to first state and try to debunk a few myths that people in our community believe about USB. I won't be mentioning any names, but at least one member of the Voron team was repeating these claims during discussions that I have witnessed. I believe it was being said in good will, in order to not let people go through uncharted waters. However, these claims are being *presented* as if they were absolute facts, which then through the word of mouth makes them into ground truths. In no particular order:

1. You need more wires for USB than for CAN
- People usually thought that you need to run a USB cable + power wires to a board to use it. This is probably due to their experiences with printer mainboards and their confusion about USB, the protocol, and USB, the cable. Theoretically, you would indeed need 4 wires for USB + 2 power wires. Practically, you can safely get away with using only four wires, similar to CANs VCC/GND/H/L, you can have VCC/GND/D+/D- [0]

2. USB cables are not motion rated
Once again, this stems from confusing USB, the cable/connector, and USB, the protocol. You can run the USB protocol over a shielded, motion-rated cable just fine. In addition, I have talked with a surprising number of people who just straight-up run USB cables to their toolheads. It has been working for them for a couple of hundred hours of printing so far. Whilst I would not recommend doing this, it seems to be a surprisingly viable strategy. The disadvantage here is that the USB connectors on the toolhead boards are usually surface mounted and could rip off if you do not fix the umbilical cable correctly so that it does not move.

3. It won't work because it is not up to USB spec/because of signal reflections/etc.
Unfortunately, I am no electrical engineer; I am a mere programmer with an interest in electronics. These issues have been brought up by people who claim to be electrical engineers. I have no reason to doubt their credentials or the truthfulness of these claims. However, the reality is often different from the theory and USB is a shining example of this. The USB specification is a mish-mash of the spec writers trying to lay down some ground rules whilst simultaneously trying to describe whatever the hell people were doing with USB out in the wild. Yes, the spec calls for a shielded cable. Are the majority of USB cables in the wild shielded properly? No --- but they work just fine. I won't be making a fool of myself by trying to talk about signal reflections or EMI, but the gist of what I would like to say is --- if it reliably works, do these theoretical problems matter? Should they be stopping us from experimenting with it?


With that out of the way, here are a few disadvantages that I could come up with. If you have any, please let me know.

- If your Pi is powered from a different power supply than the board you are trying to talk to, there could be problems. I believe that this is solvable by tying the grounds of the different power supplies together.
- If you are using a Pi Zero, you could be short on USB ports - already a problem currently and rather easily solvable with a hub
- Theoretically, you need longer wires, as USB is a point-to-point bus. Practically, we wire CAN similarly, so I don't think this would be a problem.
- Less noise immunity for longer runs compared to CAN. This might be a problem with bigger printers where the runs can get up to 2m in length, but if you use a well shielded cable, it should be fine. A bit of a chicken-and-an-egg problem --- if USB becomes more popular, there will be specialised cables available.


I am currently testing this on my V0 toolhead. I have been printing without any problems with my ghetto testing cable (it is shielded, but not that well - 1$/m recommendation from hartk) for at least a 100h. Pictures are of my testing setup. As you can see, it is really simple, uses easily available, cheap parts and could be spliced up with whatever USB cable you have at home; I just happened to have the USB screw terminal and USB-C connectors on hand.

I would like this post to start a discussion in regards to this topic. I am eager to hear your opinions and experiences.

Footnotes and references:
[0] You can share the power supply ground and the USB ground and omit the USB VBUS (5V) line, leaving you with only 4 wires that you need.

// EDIT1: Removed redundant text
 

Attachments

  • IMG_2758.jpg
    IMG_2758.jpg
    151.1 KB · Views: 161
  • IMG_2784.jpg
    IMG_2784.jpg
    153.3 KB · Views: 145
unknown.png

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
 
@hartk Thanks for sharing your experience!

The pictures are actually showing the 4-wire setup, the fifth wire is just the shielding twisted together.
 
I am playing around in KiCad making a Tee connector board for the MicroFit 2x2 receptacles, and then making a "dongle" terminator using a corresponding 2x2 plug. A Huvud at the toolhead doesn't need to have a passthrough connection (although it should) but a Huvud at each stepper certainly would.
You make a compelling argument why USB makes more sense.
 
I believe USB communication is faster then CAN buss as well.
USB 2.0 will be up to 480Mbps while CANBUS will be from 125Kbps up to 1Mbps for standard CAN.
Mind you that CANBUS is designed for reliable communication in real-time systems and is optimized for robustness and fault tolerance, i don't believe USB was made with any of that in mind.
In general EMI will be a bigger problem for USB connections compared to CAN and passing USB wires close to bigger stepper motors might pose itself as a reliability issue.
I'm afraid this is as far as i can contribute.
 
Just a thought... Would it maybe be possible to desolder the USB port on the board and solder the wires directly to it? Just for removing the port and plug... Or is it simple to small to do this at home?
 
Just a thought... Would it maybe be possible to desolder the USB port on the board and solder the wires directly to it? Just for removing the port and plug... Or is it simple to small to do this at home?
Sure you can do this but I am not sure why you would need to?
 
I have been juggling with that idea too for a while. I want to go umbelical, but CAN always felt wrong. Mostly the speed and the limitations that it brings.

A great advantage of USB would be that with a USB hub on the toolhead, one could get a nozzle cam and beacon, etc. on the same 4 wires. Something CAN cannot do. It’s not fast enough for video.

I’m think of using one of the current toolhead boards, connected via USB and adding a small hub such as the Yoctopuce. It would be even better if a manufacturer would embed one on their board. That would be the best solution.
 
USB would work well for a printhead. But of course, you want USB-C.

USB-C is currently spec as being able to deliver over 200 Watts of power. That is more than enough to power a printhead. The new standadr is called "Extended Power Range (EPR)" and can send up to 48 volts and 240 Watts.

If you are going to do USB, do it right. The print head has a microcontroller, when it wakes up it is given a small amount of power over USB. From memory, I think this is 500 milliamps. Then it requests more and may or may not be given more power. It depends on what is on the other end of the cable.

So. There is a USB plug on the print head and if you plug it directly into an Apple Macbook you would be able to flash the memory in the print head and do some testing but I doubt the Macbook would be able to run the heater. If you plugged the print head directly into the Pi3 USB port it would come up and "talk" but the request for 40W of power would fail.

You would need an device between the Pi and the print head to supply power. A would NOT hack an old-style USB cable. Buy one rated for 200+ watts.

Yes I agree that CAN is being misused by the 3D printer community. I use it in my robotic projects because I want to control 12 morter and 3 dozen sensors all on a single diasy-chained buss. This is what CAN does best.

The newest USB standard is absolutely perfect as it was designed with power delivery in mind and is NEGOSIATES the power so it will always work even if you try to connect the head direct to the Pi, or a Macbook, it will still work

Follow the current standards and please don't do a one-off solution. If a user sees a USB-c connecter, it has to work no matter what he plugs in. even if "work" means that an LED blinks an error code.
 
I have been juggling with that idea too for a while. I want to go umbelical, but CAN always felt wrong. Mostly the speed and the limitations that it brings.

A great advantage of USB would be that with a USB hub on the toolhead, one could get a nozzle cam and beacon, etc. on the same 4 wires. Something CAN cannot do. It’s not fast enough for video.

I’m think of using one of the current toolhead boards, connected via USB and adding a small hub such as the Yoctopuce. It would be even better if a manufacturer would embed one on their board. That would be the best solution.
No, do not place the hub on the toolhead. the hub mounts to the printer frame. The Pi3 plugs into the hub and also a direct line from the 24 volt PSU goes to the hub. The hub then supplies power and data to any device you plug into the hub.

There is a newish and very robust standard for doing this read more here; https://manhattanproducts.eu/pages/usb-c-pd-charging-everything-you-need-to-know

The good thing is that the cables that can handle the large amounts of power, self-identify. So if "Dumb User" tries to use a cheap cable it refuses to work. He can use a cheap cable for the webcam but not to power an Ultra High Flow hotend.

What I am afraid of is that printer makers, being cheap. Will simply hack a normal USB connects to supply 24 volt power.
 
So you are using one on a ? printer no issues? Is there a hub on the toolboard or some other way to plug a Beacon into the Nighthawk? Just trying to see what the options are.
 
Wouldn't it just plug in to the probe port instead of the inductive, Klicky, or Tap probe?

I had made a semi-snarky comment about wiring on this thing and looking at the LDO docs it finally struck me (I'm slow sometimes) that the Nitehawk board replaces all the old connections direct from the controller board with the USB from it to the Pi, and the data connection from the Pi to the controller. Neat! That's a whole lot of error-prone wiring gone.
 
Hey with regards to can bus wiring I have a history with driving trucks and did some time driving tractors and in that time on the farm we used a lot of can style wiring from memory and I would assume it would work here as well u had the wiring going through all points thinking of it like a water pipe from one source the u need a can bus terminator so the computer knows that is the end of the line from memory it did not matter who was first or last but I thi k u would need a controler at each point ie motors and tooth head then some one would need to create the program I am talking about how John deer use to run there can system hope this helps and some one with much more knowledge can work with this

Sleepster217
 
Hey with regards to can bus wiring I have a history with driving trucks and did some time driving tractors and in that time on the farm we used a lot of can style wiring from memory and I would assume it would work here as well u had the wiring going through all points thinking of it like a water pipe from one source the u need a can bus terminator so the computer knows that is the end of the line from memory it did not matter who was first or last but I thi k u would need a controler at each point ie motors and tooth head then some one would need to create the program I am talking about how John deer use to run there can system hope this helps and some one with much more knowledge can work with this

Sleepster217
I have no idea what John Deer does, but in the general usage, the termination of a canbus line is just a 120 ohm resistor across the signal lines. Most of the toolhead boards and stuff we use have a jumper to provide that functionality right on the board. The hardware (and software) is capable of doing multi-point just fine. The reason we mostly don't do long multi-point runs is that the cable paths generally just don't make sense.
 
AFAIK canbus is just a control signal protocol and can use copper or FO to move the data signals to and.fro. To get anything done you still need a module to do something with that signal and in the automotive environment this means you will need a local power source, relays and some logic to activate the device when an appropriate event is signalled to the local control module.

IME I'm not sure it is really better when everything is new and.workinf but if you have an appropriate code reader and writer you can validate any accessible module and verify device operation which is handy for more complex cars.

I hate it on my BMWs but I understand why the Germans like to use FO but it is darned expensive to do it this way.
 
Wouldn't it just plug in to the probe port instead of the inductive, Klicky, or Tap probe?

I had made a semi-snarky comment about wiring on this thing and looking at the LDO docs it finally struck me (I'm slow sometimes) that the Nitehawk board replaces all the old connections direct from the controller board with the USB from it to the Pi, and the data connection from the Pi to the controller. Neat! That's a whole lot of error-prone wiring gone.

AFAIK the Beacon eddy current sensor uses standard USB port protocol with a non-USB defined connector at the sensor circuit board. The supplies cable has the matching non-standard connector cables directly to a conforming USB Type-A connector at the RPi board USB port.

So AFAIK this precludes the use of the 3 pin PROBE connector which supplies 24v, ground and a single data line to the MCU. This is not to say some sophisticated persons couldn't install or or tap existing Nitehawk circuity to supply 5V to power the Beacon, highjack the unused GPIO 11 pin to use for the other required USB data line and write some very fiddly bytes to ID the new Beacon dedicated USB device to the MCU so it is treated as a standalone USB device.

All of this complication was why I asked about putting a USB hub chip at the head of the Nitehawk board and plugging in the Nitehawk and Beacon to use the common cable back to the USB adapter under the deck of the Voron.

I'm not an engineer so to me this seemed doable in a functional block diagram way.
 
Top