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.

[A_Camera]

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.

That's a plugin problem not Mach3. Mach3 doesn't know about USB at all since it is a parallel port based software.

[m_c]

That's a plugin problem not Mach3. Mach3 doesn't know about USB at all since it is a parallel port based software.

It was a problem exasperated by Mach3's architecture.
You are correct in saying Mach3 was originally written only for a parallel port, but that meant that it wasn't well designed to have a plugin controlling motion flow, and is why the problem was so critical.
Mach3 simply output the motion, and the plugin was expected to handle it. Should the plugin not be able to handle it, and needed to halt the incoming motion, it could halt the motion, but it had no way to reverse back should anything get lost. It was a balancing act between buffer size, and how long you could allow for timeouts to occur/recovery to be started.

You could set a large several second long buffer, but that delays any changes in Mach from happening at the machine, so is not good, but allows more time for any communication issues to be handled.
But if you keep buffers short, it limits how much time the plugin then has to handle any communication issues, and also risk buffer underflow.


This all led to the problem that if you ran say one second worth of buffer, which could potentially be several blocks worth of G-code, and communication stopped. The plugin would know where communication had stopped, but it had the problem of having that second worth of g-code in it's buffer, and no way of rewinding Mach back to the block where motion had stopped. You were then in the problem area of how do you recover from that point?

The same problem applies to Ethernet controllers, however as they're less likely to suffer from communication issues, it's not anywhere near as big a problem.


For an example of how USB can be done well, look at a KFlop. The KFlop and KMotionCNC continually exchange information. The buffer is transferred a set period in advance, but KMotionCNC on screen only advances a block, once the KFlop has told KMotionCNC that that block has been physically completed. KMotionCNC always knows where the KFlop/machine is, and KFlop has the ability to tell KMotionCNC it's lost a packet, and to resend it. It also has the ability to tell KMotionCNC to run in reverse. KMotionCNC also has the ability to flush the KFlop's buffer so any on screen changes (i.e. SSO or FRO) happen much faster, and not be slowed by the buffer time.
If you unplug a KFlop mid-job, it'll run until it's buffer empties then halt, and KMotionCNC will warn you it's lost communication. Plug it back in, KMotionCNC will learn where motion was halted, and on clicking cycle start again, it'll continue from where it halted, just as if you'd activated a feedhold.

I'm sure other controllers with dedicated software are also using similar methods, but it was a capability Mach3 just didn't have.

[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

[magicniner]

Funny, I never get a failed/partial file download because of missing packets ;-)

I think you're pointing out the minor shortcomings in a system which have no impact whatsoever on the application being discussed :D

[A_Camera]

Funny, I never get a failed/partial file download because of missing packets ;-)

I think you're pointing out the minor shortcomings in a system which have no impact whatsoever on the application being discussed :D

Downloading of files and handling of hard disk is not real time activity so packats can be resent any number of times. The checksum of the file and the packets will tell you if there is a need for resend.

[m_c]

Smilies are wasted on some people :D

[magicniner]

Smilies are wasted on some people :D

Very true.
They also tend to use technical arguments which they patently misunderstand to prove that something which works very well ought not to :D