I agree! And this is why USB has issues! :-(
Dave On 3/2/2014 8:37 AM, Philipp Burch wrote: > Hi Steve, hi everyone! > > On 03/02/2014 12:41 AM, Steve Blackmore wrote:> On Sat, 01 Mar 2014 > 18:15:29 +0100, you wrote: >> >>> When I've learned something about hardware interfaces and reliability > in the past two or three years then it is to stay as far away from USB > as possible whenever something else than a classical HID (Mouse, > keyboard, flash drive, etc.) should be connected to a computer. >> A bit of a sweeping statement :) > Of course, I always try to make sure that my point of view is clear ;D > >> There are good USB based controllers out there that work perfectly well. >> All depends on good hardware design and how the software/firmware uses >> it. The majority are poorly implemented and poor PC setup also > Yeah, everything depends on if it has been done right. But consider the > isolation problem as an example: USB isolaters give "varying results" > (to cite someone else). Why is that? Well, USB uses a single twisted > pair for RX and TX, which makes it extremely hard to build an isolation > device that does not interfere with the traffic. Simple transformers (as > with Ethernet) don't work, because the data is transmitted NRZI-encoded, > so contains DC. An isolator most likely identifies itself as a hub, so > there is already additional traffic just to have working isolation. > > You could now argue that the isolation should be done in the slave > device (such as the controller, just like it is usually done with > RS232/RS485) after the USB interface. Of course you can, but then you > have most likely much more complexity added than if you'd used Ethernet > in the first place. > > Another thing that can hit you when using USB is the very limited length > of the cable (5m or something). If the interface is used locally on a > machine, then this MAY suffice, for anything remote it is almost always > too short. > >> contributes a fair amount of problems. In windows most don't turn off >> hardware power saving and then moan when the USB port goes to sleep. In >> fact the majority aren't even aware it exists or where to find it! BTW - >> same applies to ethernet ports ;) > Software configuration is a completely different story. At least I never > had any such issues with an Ethernet port, but thanks for the hint. See > below for my statement concerning other software considerations. > > > On 03/02/2014 09:20 AM, Steve Blackmore wrote: >> On Sat, 01 Mar 2014 21:19:06 -0500, you wrote: >> >>> I've had a number of problems when plugging into industrial devices that >>> have a USB interface. The lack of isolation is oftentimes a problem. >>> Othertimes my laptop will confuse the industrial device with another >>> common USB device like a stick drive, even if the driver for the >>> industrial device has been loaded. >>> I've never had similar issues with RS232 or Ethernet interfaces. >> The idea behind USB is good but is often let down by OEM penny pinching >> on design, firmware and software. Many devices simply do not meet USB >> standards and the myriad of different things a USB device could be can >> make it a lottery sometimes. >> >> Laptops are particularly bad - hidden power saving that you can't >> disable, even via bios and half baked hardware, like you say with >> isolation, or alternately a lack of ground problem. I've seen the >> confusion problem too, not only with laptops. "Plug and pray" sometimes >> doesn't. Again, crappy hardware, power saving or driver problems. > Ok, (cheap) laptops probably aren't suited for an industrial environment > either ;) Except for some non-critical HMI maybe. > >> The most common fix is always install any supplied drivers WITHOUT the >> device plugged in. Also cycling the power by shutting down then removing >> batteries, and/or mains for a few minutes often fixes confused PC's. >> >> RS232 is becoming rare on modern devices, it's slow and single ended and >> relies on a common signal ground between devices. That can introduce >> it's own problems. >> > RS232 has the advantage that it is so damn simple, you can debug almost > everything by just hooking a scope (or even just a pair of LEDs) to the > data lines. And it can easily be implemented in even the tiniest devices > that have something like a stable timebase. I like to have this > interface at hand (optionally with the electrical improvement of using > RS485) as a very basic debug interface. For this, it mostly even works > with a USB/RS232 adapter. > But again: Not for the process data itself during normal runs, but only > for development and debugging (probably initial configuration as well). > >> Ethernet is complex and needs careful design to work at all - hence it's >> expensive. >> >> See >> http://www.iebmedia.com/index.php?id=8777&parentid=74&themeid=255&showdetail=true > That depends. On the electrical side, see above. If isolation is > required (which is almost always required in an industrial context), > then Ethernet is no more complex than USB. Just have a look at some of > TI's Tiva microcontrollers: Those have an Ethernet MAC AND a PHY > integrated, so all you need externally is a connector with the > integrated transformers and a few passive components. That's still a bit > more expensive than the (non-isolated) USB variant, where you do not > need the transformers. But it is simply a question of routing two > differential pairs on the PCB with adequate termination, so no more > difficult than with USB. > > The great advantage of Ethernet compared to USB is on the software side: > Have you ever needed a driver for any network-connected device (except > the NIC itself, obviously)? I haven't and therefore I also never had any > trouble with the following: > > 1. Buggy drivers > 2. Unsupported platforms (OS version or entirely different OS) > 3. Accessing the driver/interface from userspace > > 2. and 3. really make Ethernet (or another network connection) shine > compared to USB: No hassle with things like LibUSB, missing privileges > to install a driver, etc. Just create a socket, connect to the remote > host and there is your connection. And this is easy in almost every real > programming language on every platform. > > The only thing that can be a bit difficult is to get an IP address into > the device (DHCP is a bad choice for anything working as a server). This > is where the debug interface is useful. Or it may just have a default IP > programmed, which can then be used for initial configuration. > Having a static IP address in the device also makes identification easy. > It just doesn't matter where it is placed or into which connector the > cable is plugged. > > Ok, enough said. That's my point of view, but everyone may decide on > his/her own about which interface to use for anything. Just as a hint: > If you need to think more than 10 seconds about which USB class a device > fits in, then it's probably the wrong choice of interface ;) > > Kind regards, > Philipp > > > > ------------------------------------------------------------------------------ > Flow-based real-time traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate reports. > Network behavioral analysis & security monitoring. All-in-one tool. > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > > > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users ------------------------------------------------------------------------------ Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
