Why Ethernet instead of USB?

[jtar40]

Hey there!
I got a lot of recommendations on the uc300eth, the uc400eth and I've heard decent reviews about the Ethernet smooth stepper,
I know that I'm going to be probably buying one of the "UC series" but just out of curiosity is there a reason why Ethernet interfaces have seemed to be more reliable than USB?

[Neale]

Yes - Ethernet gives ground separation between the two ends (good in industrial situation where bits of kit may be on different mains supplies) but also helps reduce noise issues, and the cabling is twisted-pair and differential signalling, also good for noise rejection. Fundamentally more reliable, which is why an Ethernet connection can be much longer than USB. USB can be pretty good but Ethernet is undoubtedly better. However, in most home workshops, USB is probably fine, but if the cost difference is not very much, I would always pay a bit extra for Ethernet.

Depending on how your pc/network is configured and how happy you are setting up network addresses and so on, an Ethernet motion controller might need an extra network hub, or its own network interface in the pc. I run my CSMIO Ethernet motion controller on its own separate network, and have a wifi adaptor in the pc to talk to the house network for file-sharing, etc, but that's just to suit my own network situation (and I'm happy playing with network parameters anyway)

[A_Camera]

As Neale said...

But what he did not mention is that the actual communication protocol standard for Ethernet is also much better than that for USB. Ethernet protocol is faster, more reliable and robust because it has a built in error correction algorithm which is not existing in USB. This alone motivates the little extra cost quite well, even in a home environment. Personally I had the UC300USB before, but even if it is also a very good controller, it had reliability issues, whenever I started the vac it crashed the communication because of the spikes the vac motor caused. This was pretty frustrating, so I bought the UC300ETH and that solved all the issues. Of course, the ETH is a bit more complicated to set up if you are not familiar with LAN configurations, but it is definitely well worth the effort. It is also offering huge flexibility, since you don't have to have a wire connected between the CNC and the PC, you can run it through Wi-Fi LAN, as well as through a LAN switch, or if you prefer, you can run it via a direct LAN cable, just like if it was USB, with the exception that the UC300ETH must have it's own power supply, as opposed to the USB controllers, which can take the 5V from the PC via the USB.

[Ger21]

When comparing CNC Drives USB controllers to their ethernet controllers, also be aware that the etherenet controllers have faster processors, which allows them to have faster pulse rates, and to support some features that the USB controllers do not.

[Doddy]

My take on it (and I may well be wrong):-

Neales correct with the ground isolation - in fact the whole of the physical layer interconnect has been well designed for reliable data transmission, with isolation transformers providing galvanic isolation as well as a well balanced interconnect onto the network. The networking cables themselves perform to a known standard. The low-level signalling is designed to aid reconstitution by ensuring that there are level transitions regardless of data content that allows the transceiver (or receiver, in this context) to lock onto the datastream reliably, as well as minimising EM-emissions.

USB, like Ethernet, is also a differential drive system over twisted pair - all designed to minimise the influence of external noise, and to limit the generation of noise (low-speed USB recommends, but doesn't require the twisted-pair; high-speed designs require it).

Neither system provides innate error correction. Both systems provide error detection - and it's up to higher-level protocols to manage the error handling.

The two interfaces are designed around different use-cases. USB was designed to address the explosion of interface types on peripheral devices, and suited to the typical PC desktop type of environment. Ethernet was designed for reliable high speed communication in an industrial environment over long distances.

You pays your money, you takes your choice.

[Neale]

I had always assumed that USB was single-ended with a data signal in each direction. So I did what I should have done anyway and had a quick look at some better descriptions. Looks as if USB devices must have both send and receive capability on a single twisted-pair and indeed use differential signalling. Most of the time... Apparently single-ended signalling can also be used for a few special cases - maybe device reset, for example. Which might explain why USB is normally OK, but can give the odd problem. As for transmission protocols - it's certainly true that TCP will generally handle errors on an Ethernet (IP) link, but it's up to the designer of the USB device to decide if they are going to implement error detection and correction. And who knows what they do under the covers?

Given the problems of diagnosing noise-related issues, I would tend to go Ethernet to give the best chance of not having to diagnose them in the first place! But then, I've been playing with Ethernet since the days when you had to drill the chunky coax cable to fit each device adaptor...

[Doddy]

I would tend to go Ethernet to give the best chance of not having to diagnose them in the first place!

Absolutely. I value my time more than wasted hours debugging an unreliable system. I have experienced unreliable operation over USB on a RepRap 3D printer. For the mill I got a cheap ethernet motion controller; I have, this week, taken delivery of a UC300ETH. For me, ethernet all the way.

[m_c]

but it's up to the designer of the USB device to decide if they are going to implement error detection and correction. And who knows what they do under the covers?

That is the main problem with USB.
Some controllers just can't handle errors.

Mach3 was especially bad, as should a USB problem occur, Mach3 itself would lockup and become unrecoverable.

[magicniner]

it's up to higher-level protocols to manage the error handling.

Given the lack of support for Banyan Vines, Token Ring and other legacy networking protocols, what's the chance of using Ethernet without TCP/IP and all it entails and thus what's the point of that point? :D

[Doddy]

The point of that was to address an earlier comment that Ethernet provides error correction - which is certainly not a part of the lower comm layers. In fact, TCP/IP doesn't provide error correction - merely a retry mechanism.

TCP/IP isn't the be-all/end-all. For the last few years I've been involved in an engineering activity centred around UDP.

:D