LAN vs USB - Pros and Cons for Programmable Test Equipment?

[Plasmateur]

Almost all test equipment I've used has been controlled over USB, but there is a power supply I want to purchase that is much more affordable by going with the LAN option than the package that includes GPIB, USB, and LAN.

So I'm considering to just switch everything over to LAN and running everything off a switch. This seems better in terms of cable management.

Are there any pros and cons I should be aware of for switching over to LAN? Mainly I'm concerned about response times of the devices. 

[madires]

Ethernet comes with isolation for free if you use cables without shielded RJ45 plugs.

[Nx-1997]

I use a usb over ethernet adapter, precisely, the extron usb extender. Works really well. Data transfer is around 35MB/s. Older test equipment generally don't come with LAN capability, but they do support serial/gpib/usb.

[PKTKS]

Ethernet comes with isolation for free if you use cables without shielded RJ45 plugs.

TRUE.

As a matter of fact USB  based port for bench sucks !!!

HP products are wild in USB support - not even their calculators
can be kept working among USB versions.

The whole USB stack is a mess - OHCI EHCI xHCI..  none can actually
solve the issues of a safe compatible link - as RS232 or ETHERNET.

ETHERNET is kept working sane as safe as long as I cam remember.
10/100/1000 and you just plug the thing - the OSI IP stack handles that.

can not say the same for the crappy USB stack these days.

Paul

[tszaboo]

Programming them over ethernet is a lot simpler. If you connect it with USB, you need to download and install drivers, pray that they work with USB 3, mess around with INIs. With ethernet, you open a port and you get a SCPI interfce, where you can just send commands. Just like a serial port. It is a lot simpler.

[ddavidebor]

LAN is great, everything works 10 times better.
Especially if the instruments are fully LXI compliant

[Electro Fan]

+1 for LAN

[joeqsmith]

I hate using USB and have many nightmare stories.   It's just not robust enough, even for the mouse and keyboard.   

That said, my SA uses USB3.  It would not work at all with my laptop.  I bought a new desktop just for this reason. It would not work with that as well and I ended up buying a 3rd party USB board and it's been fairly solid since.   I haven't looked into the physical layer but I suspect USB3.1 is more robust.

If I could have everything on Ethernet, I would. 

   

[colorado.rob]

There are exactly zero reasons to prefer USB over Ethernet when connecting test equipment for lab automation.  For field work, sure.  USB to a notebook will be easier.  In the lab USB is a pain to work with.

[David Hess]

Like others mentioned, Ethernet has built in galvanic isolation which is a huge advantage over other standards like USB, GPIB, and RS-232.  Also:

1. Ethernet has essentially unlimited range.  If 100 meters is not enough, then bridges and switches can extend it, (1) and fiber bridges and transceivers and wireless bridges are inexpensively available.  Custom cables can be made inexpensively.
2. Ethernet layer 2 is locally routable automagically and Ethernet layer 3, which is typically IP, is routable globally.  So control can be exercised from anywhere an internet connection is available.

(1) And hubs but I think I may have the last Ethernet hub in service.  Ethernet hubs sometimes have advantages over Ethernet switches.

[BravoV]

There are exactly zero reasons to prefer USB over Ethernet when connecting test equipment for lab automation.  For field work, sure.  USB to a notebook will be easier.  In the lab USB is a pain to work with fashion statement and a life style.

There, minor corrections.   

[kripton2035]

also USB needs a driver to work. Ethernet doesn't.
USB works until the next major system update, then if it's a standard HID it may continue to work
if it's not HID the manufacturer of the device has to update the driver. if he wants to.

[maxwell3e10]

I am always amazed by tens of MB drivers for USB instruments needed to send a few bytes of ASCII

[dietert1]

For lab automation, i.e. equipment that is supposed to work without supervision, USB isn't reliable enough. For applications like that i prefer screw secured plugs. How well an Ethernet connection works, depends a lot on the protocols used. I remember many discussions about streaming audio and we found several common protocols did not include repetition of faulty packets (for simplicity and for performance reasons). Then an Ethernet connection may also lose data or get stuck. Maybe one has to live with a "good enough" solution, that hangs every now and then and needs administrative help.

Regards, Dieter

[mansaxel]

Ethernet.

Though, there are lots of ifs and buts there too.

• You will need some infrastructure. For me, who does networks for a living, that is no problem. I give the devices fixed addresses in my DHCP server, and put them on a separate lab LAN, with firewall rules to the rest of the network. I do not trust Vendors (regardless of country) with keeping themselves secure.
• Lost packets. Well, that is what TCP is for. Most serial emulations on top of IP  use TCP, so moderate (10^-5 packets lost or less, which is generous and very easily achieved on a lightly loaded switched L2 network.) packet loss is not a problem.
• There is the issue with lack of timing precision. If you need precise synchronisation between instruments, Ethernet is a challenge, but it is doable. IEEE1588-2008 is easily capable of achieving 1µs timing precision over very large networks, providing you buy quality switches. Netgear and similar SOHO crap won't do. (TBH, I don't think USB will do that very well either, not unless it's been considered from the start.)

[TheUnnamedNewbie]

With regards to timing: I don't think it's really an issue, if you need accurate timing you should do that through another means anyways (through a 10/100/1000 MHz shared clock, external triggers and gates, etc).

USB is nice if you need something simple and portable. I've used it to just program some powersupply/SMU sweeps when probing a broken IC - the SMU is behind the probestation so hard to get to, and I usually want to save the data anyways. Just plugging the USB cable into the laptop and running a 10-line matlab script is easier there than dicking around with figureing out the IP, opening the firewall, getting a switch, etc. But for larger setups, ethernet is just the better choice. You don't have to deal with USB hubs that never seem to work, it's easier to deal with IPs, and you get the isolation for free. And you get the remote-option for free - need/want to verify that 72 hour sweep is still going? can easily just remote into the system from anywhere in the world with a network connection.

A downside of ethernet (I've been told) is speed when sending lots of commands - I was told much of the standard libraries for Matlab/Python/ETC use one packet per command. So if you need to very quickly sweep over large ranges of settings in eg a multiplexed data-logger (EG, on a multimeter, open previous switch, close next switch, set range, set NPLC, read data, open switch), you get clogged up by the fact that you have a lot of protocol-level overhead and latency. You need to manually fiddle with the packets (in Python, don't know about MATLAB myself) to make this more efficient.

[mansaxel]

A downside of ethernet (I've been told) is speed when sending lots of commands - I was told much of the standard libraries for Matlab/Python/ETC use one packet per command. So if you need to very quickly sweep over large ranges of settings in eg a multiplexed data-logger (EG, on a multimeter, open previous switch, close next switch, set range, set NPLC, read data, open switch), you get clogged up by the fact that you have a lot of protocol-level overhead and latency. You need to manually fiddle with the packets (in Python, don't know about MATLAB myself) to make this more efficient.

As you allude to, this is not a fault of the network as such. It probably is the tower-of-kludges that comes from "this used to be a GPIB command that went RS232 and now is TELNET " that serialises the communication. If your lib did some clever comms, 1*10⁵ commands per second would not be a problem. Just toss them in an UDP datagram per query and watch the end nodes melt with the network being essentially business-as-usual. Every PC that can run a supported Windows (for those who suffer from that) easily does 100kpps from a GE port.

[NiHaoMike]

I have worked with quite a few Tektronix scopes that won't work reliably with USB but work just fine with Ethernet. Also, when downloading the waveform data, doing it over HTTP is for some reason a lot faster than doing it over LXI.

[Gribo]

+1 for Ethernet. Even top tier brands (Tektronix MSO2024) have bad USB stack, not to mention 3rd party driver suppliers such as Windriver, which also cause compatibility issues.

The only instrument I encountered with bad ethernet module was an Agilent SA which didn't officially support it. Using the LXI interface caused the instrument to freeze.