Why Ethernet instead of USB?

[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.