Quote Originally Posted by FatFreddie View Post
I suspect that the underlying UDP ethernet protocol is nearly as error prone as the USB protocol, however, the TCP/IP layer which sits above it and does the error correction is (as has been pointed out) extremely robust so the end result is much better.

I can see both sides of the argument but theory is worth nothing if it doesn't work in practise...

For what it's worth, I've got a 3D printer which is extremely noise sensitive on the USB connection (to the point I now download the print to a memory card and print from that) and a USB CNC controller which I haven't had a problem with but there are dire warnings on the website about using a good quality cable - see https://www.youtube.com/watch?v=NUu9xwDfJ9k
Looking at a USB cable, it appears to use ground, power, and data in and data out. So, single-ended connections. Typical Ethernet connections use twisted-pair and, presumably, differential signalling. That suggests that Ethernet, at a hardware level, should be intrinsically more noise-resistant (although my own 3D printer has run for many, many hours over USB without any problem, although that is in a domestic environment without machine tools and EMI generators nearby). I think FatFreddie has it right with reference to TCP, though. A typical USB connection will be using an application-specific protocol that assumes a reliable connection (I know my 3D printer does this as I've looked at the code) so any data corruption or loss will be catastrophic, where the TCP protocol gives a highly reliable connection; any packet loss or corruption short of losing the whole connection will be detected and corrected by resending packets. Ethernet-connected motion controllers appear to use IP as they need network addresses and I presume they also use TCP over this - why shouldn't they? So, an error-correcting protocol over a more noise-resistant hardware connection gives so much more safety margin than a simple protocol over less-protected hardware. Be interesting to see the Ethernet-level error counts in a noisy environment, though.
What you are losing, of course, is any claim to a real-time protocol, but as the network connection is being used to transfer, typically, high-level movement instructions which can be easily buffered, by buffering a couple of seconds'worth of data you can still withstand a short loss of communication during a noise burst, the TCP stuff does its job and makes sure the data gets there eventually, and the pulse generator bit of the motion controller chunters away happily working from buffered data.
Conclusion - theorist meets practical experience, shakes hands, and goes off for a pint...
Personally, I like learning from experience, and preferably someone else's experience 'cos that costs me less! But trying to relate that back to theory might give a bit more insight sometimes and lead to a better understanding and maybe a way to move forward. Cathedral builders used experience to create magnificent buildings but theory and better understanding of materials gives us skyscrapers. If that is an advance...