Is USB a Genuine Alternative to GPIB and RS232 in Instruments?

[amspire]

Just about all the instruments I have used seem to keep going for decades, unless someone manages to blow something up.

All the instruments from the 60's, 70's, 80's and 90's that used RS232 or GPIB interfaces are still completely useable as long as a decent user manual is available. In another 50 years, you could make a new RS232 adapter, or a GPIB adapter from the IEE488 specifications and talk to these instruments even if the computers in 50 years are unrecognisable from today's computers.

How about USB interfaces? They seem to need custom drivers and usually the manuals do not specify the full protocol. Often, it is a matter of "install these drivers, run this program, press these buttons and look at the graphical results"

I suspect that in 20 years, it will probably be very hard to talk to any pre-2015 USB-based instruments. Even if the instrument offers alternative ways to dump data, such as a USB memory socket or a SD card slot, it will probably be impossible to get these forms of memory in 20+ years.

Is there any modern GPIB alternative on the way? I think that Ethernet interfaces are closer to an ideal, long term general purpose interface then USB.

Here is my wishlist:

• Reasonably simple hardware. Simple enough to rebuild from scratch in a few days without needing special interface IC's
• Serial-based
• No custom ID's required
• Parallel-able instruments would be nice (like GPIB).
• Can be used across different transmission medium - wire, wireless, IR, near field inductive coupling
• Electrical Isolation from instrument
• Capable of extremely low powered operation
• Instruments have a set of text-based commands available, even if there is another binary protocol avaliable. The text-based commands must be described in the instrument's manual.
• Non-proprietry

[Maxlor]

USB is fine as long as it's CDC (i.e. emulated serial port), it'll keep working. Anything that needs custom drivers... eh, it'll be a pita in 10 years, or downright hopeless :/ Even now, I feel like some devices make me jump through a lot of unnecessary hoops with that USB driver thing.

Having ethernet and some protocol info available is nice. Especially if it actually works reliably 

[amspire]

USB is fine as long as it's CDC (i.e. emulated serial port), it'll keep working.

The trouble with USB in this respect is USB insists on using ID's, so a serial chip has to have a driver that is owned by someone. This stops a truly generic solution being developed with no unique ID, and it leads to all the FTDI/Prolific driver issues and anti-clone battles.

The USB ID is all about plug and play.

With instruments, you just want it to keep working for years. You want to be able to talk to any instrument without the need for any instrument-specific driver at all. GPIB and Ethernet never had a dedicated unique manufacturer/device ID, and both those solutions have worked pretty well.

[tszaboo]

I love and hate USB instruments. They are fine when they work, usually they dont. You need a properitary software to make it work. Like the agilent connection expert (or whatever they call it this week). 300 MB of woopy-do.
Also, it prevents you for doing nice closed calibration systems. We had a system, plug in a 34401A on the serial port. It sent commands to the meter (the microcontroller running the code) and it calibrated out device. No PC, no external stuff.
The new system. You need a linux computer running the commands. 34410A plugged into ethernet, sys admin making sure that the IP is ok, DNS is OK. Linux talks to DUT over ehternet, 34410A over ehternet. You need a PC to log into the Linux machine. You need a stupid software clicking around to do the calibration. And a spaceship and a submarine. And it is slower, because programmers suck big time.
So yeah, RS232 and GPIB rocks. And we need an alternative for USB, preferably one which is not designed by any of the people working at USB.

[Fungus]

With instruments, you just want it to keep working for years. You want to be able to talk to any instrument without the need for any instrument-specific driver at all.

Yep. Just wait for Microsoft to change Windows enough so that a driver stops working, and ... then what? Throw it away? Or do you do what I do with my Canon Scanner - keep a Windows XP machine around so I can scan things. 

(yeah, I know, nobody around here uses Windows)

[Rerouter]

Fungus, if you really have your heart set on it, fire up xp on a virtual machine to talk to all those older bits and pieces,

That or look around, you may be lucky enough to find a group supporting it,

I agree there have been a few devices i have had to rebuild the interfaces on due to support being lost on XP SP2, and it was getting too painful to keep the old xp machine running (low run product from a company that no longer existed), in these cases it was just a RX TX that went through some crudged together usb interface, and could be replaced with a modern chip emulating a com port,

[amspire]

So yeah, RS232 and GPIB rocks. And we need an alternative for USB, preferably one which is not designed by any of the people working at USB.

What I was thinking of was really a modern GPIB. When GPIB was developed, most micros couldn't do fast serial and so that had to use parallel. The ugly unbalanced parallel port interface restricts the maximum speed to about 1MHz, limits the cable length and makes you use the big fat expensive gpib cable.

Hp did make a serial version that never caught on (HPIL wasn't it?), but I am sure we can do better today.  Just give a device an address - like 6, 10, 99 - and it can talk. No more setting up.

There are some nice features in GPIB that would be worth keeping, like the Trigger. This is a single command that triggers all devices waiting for a trigger simultaneously. When you are graphing data from several instruments at once, it helps to know that a group of measurements were all taken at the same time.

[JPortici]

With instruments, you just want it to keep working for years. You want to be able to talk to any instrument without the need for any instrument-specific driver at all.

Yep. Just wait for Microsoft to change Windows enough so that a driver stops working, and ... then what? Throw it away? Or do you do what I do with my Canon Scanner - keep a Windows XP machine around so I can scan things. 

(yeah, I know, nobody around here uses Windows)

Windows 10 already does that. Overall a good os but things become scary when you don't have dedicated drivers
The price you pay for computer based instrumentation, I can still go inside some workplaces and see 3.11 or '95 machines hooked on CAM/CNC machines

Anyway, thunderbolt or something like that could be nice in the future, at least as a concept. a pci/parallel bus on a serial cable

[Lukas]

I don't see your problems. There's the USB test and measurement class (USBTMC), specified by the USB forum. If you implement this one properly, you can be sure that your device will work in every environment. Unfortunately, on windows you'll have to use the really bloated NI or Keysight VISA, but they do the job.

• Reasonably simple hardware. Simple enough to rebuild from scratch in a few days without needing special interface IC's

Check, just use an off-the shelf MCU with USB built-in.

• Serial-based

USB is serial

• No custom ID's required

There's http://pid.codes/ The id isn't exactly important since USBTMC has its own device class.

• Parallel-able instruments would be nice (like GPIB).

There are USB hubs.

• Can be used across different transmission medium - wire, wireless, IR, near field inductive coupling

• Electrical Isolation from instrument

There are USB isolators. Any sane manufacturer should have taken care of that on the instrument side anyway.

• Capable of extremely low powered operation

If that means that you don't need an external power supply, yes.

• Instruments have a set of text-based commands available, even if there is another binary protocol avaliable. The text-based commands must be described in the instrument's manual.

I haven't come across an instrument from a reputable manufacturer that doesn't understand SCPI commands.

• Non-proprietry

USBTMC is an 'open' standard. You can go to usb.org and grab the spec. As far as specs go, it seems not too difficult to implement. Maybe I'll have a go at implementing it on top of libopencm or the chibios hal.

If some random chinese manufacturer decides to implement some funny binary protocol over USB-HID, they're the one to blame, not USB. They could have implemented USBTMC and SCPI.

One of the only shortcomings of USBTMC is that it can't provide exact timing synchronisation, you'll need something like a USB[/list]

[mikerj]

IME ethernet is a better replacement for GPIB, and many instruments now provide this interface. Ethernet provides the isolation required to prevent unwanted ground currents flowing unlike a vanilla USB interface, and there's no issue with driver problems.

However neither Ethernet nor USB permit daisy chaining of devices, so a hub/switch of some kind is always going to be needed when you have many instruments to control.

[joeqsmith]

How about USB interfaces? They seem to need custom drivers and usually the manuals do not specify the full protocol. Often, it is a matter of "install these drivers, run this program, press these buttons and look at the graphical results"
...

Is there any modern GPIB alternative on the way? I think that Ethernet interfaces are closer to an ideal, long term general purpose interface then USB.

Here is my wishlist:

• Reasonably simple hardware. Simple enough to rebuild from scratch in a few days without needing special interface IC's
• Serial-based
• No custom ID's required
• Parallel-able instruments would be nice (like GPIB).
• Can be used across different transmission medium - wire, wireless, IR, near field inductive coupling
• Electrical Isolation from instrument
• Capable of extremely low powered operation
• Instruments have a set of text-based commands available, even if there is another binary protocol avaliable. The text-based commands must be described in the instrument's manual.
• Non-proprietry

Sadly, data rates never made it on the list.   Personally I would never want to see USB on any test equipment, mainly because the physical layer is not robust.  Any time I work on something that emits some noise, the mice go first, then the keyboards, then the hubs.   Well, I guess I don't know about USB 3.   

I like Ethernet because it is an industry standard that has been around and continues to evolve.  Its very robust,  isolated and fast.   The problem I see with it is getting the software right on both ends.   The first equipment I used from Tektronix with Ethernet was a total bust.  GPIB was faster than a 100Mb link because their software was so poor.   Early versions of the LeCroy software were buggy but fast.  Here is my old LeCroy with a 1G Ethernet card installed.   Like to see you move that sort of data with GPIB.



With old equipment, transfers were small so the speed really was not a problem.  The only time it has been a problem was attempting to upload large amounts of data into an Arb that had a fair amount of memory for the time.  I have two of the Ethernet GPIB controllers that I use to automate my equipment.   These are only 10Mb and work fine.   But those large cables run everywhere and must add 10 lbs to my bench. 

[joeqsmith]

Ethernet provides the isolation required to prevent unwanted ground currents flowing unlike a vanilla USB interface, ...

BINGO!! Stupid common mode problems with USB   

[amspire]

Sadly, data rates never made it on the list.  .....

No it didn't because I am in two minds about it.

On one side, I want a simple, slow interface that I could put into every box I use a micro in. Probably for most things, even a few readings a second is useful, and many kinds of data transmission mediums like IR, near field and cheap 433MHz transceivers has a low data rate.

On the other side, you have instruments like oscilloscopes that can produce data at enormous rates.

Perhaps I am thinking about a two tiered system with a 9600 - 38,400 baud rate, plus a high speed mode. The low speed mode would be simple to implement on any hardware. The high speed would need custom interface chips.

There is no perfect solution, so what is the most useful? There is always Ethernet for high speed and when Gigabit is not enough, there is the 10G Ethernet already.

[Fungus]

Fungus, if you really have your heart set on it, fire up xp on a virtual machine to talk to all those older bits and pieces,

It's just an example of a perfectly good device that became "legacy" because of lazy manufacturers.

I only scan stuff a couple of times a year so as long as my XP laptop keep on working I'll use that.

[Jeroen3]

Ethernet provides the isolation required to prevent unwanted ground currents flowing unlike a vanilla USB interface, ...

BINGO!! Stupid common mode problems with USB 

Don't forget that there is not yet an isolator for anything above USB 1.1. Requiring isolating inside the product for anything high bandwidth.

Ethernet is a valid alternative for parallel or serial interfaces. You don't need any extra cards. *you might need an additional NIC if you want to go full bandwidth*

[nctnico]

How about USB interfaces? They seem to need custom drivers and usually the manuals do not specify the full protocol. Often, it is a matter of "install these drivers, run this program, press these buttons and look at the graphical results"

A decent piece of equipment uses USBTMC which is a broadly adopted standard and works just like a serial port / GPIB interface. For communication USBTMC uses an SCPI text based command protocol. A generic USBTMC driver should be all you need. The real problem is Windows being so lame not to support these kind of standards out of the box (maybe WIndows 10 does?).

[Wuerstchenhund]

Is there any modern GPIB alternative on the way? I think that Ethernet interfaces are closer to an ideal, long term general purpose interface then USB.

I'd say if you have somewhat modern kit then go with Ethernet. It's fast, reliable, can go over really long distances, and is robust. At work it's pretty much the standard way of connecting test gear, only for some really old devices we still use GP-IB.

USB is generally fine for simple instruments that are sitting close to a PC anyways, i.e a DMM. The problems often start when multiple instruments needs to be connected to the same PC, especially when they are located further apart. Also, as others said USB is pretty slow.

[Fsck]

ethernet is really the only viable replacement right now. it's why there are GPIB->ethernet converters.

there's really no way that having a dozen instruments over USB of any flavour will work nicely. gpib was designed purely for instrumentation, and its features reflect that.

learn to love LXI as there isn't really anything else that has both functionality and is low cost.

gpib was (I believe) supposed to be high end, it's replacements are also in the same price range. the high end automation is headed towards "chassis" like PXI or AXIE and such backplanes where you then interface to it using ethernet or something else.  either way, the current trend is to increase abstraction while combining many instruments into one externally accessible interface.

in theory, a standard based off of infiniband would work well, but be high cost for it's high performance. something off of PCI-E might be a viable replacement (through thunderbolt or however else you want to carry it over) but you might risk it dying off. you would still need to get everyone to agree on a set of standards...

[tautech]

Interesting thread this.....even Siglent recognise the need for multiple I/O's in their equipment and provide a USB to GPIB adapter as an accessory for their equipment.



http://www.siglentamerica.com/prodcut-fjxx.aspx?fjid=1198&id=176&tid=37&T=2

[amspire]

I really like the fact that Siglent has those GPIB adapters - I am guessing I probably do not like the price. For some reason, GPIB = $$$$.

I thought I would dig up info on the HPIL spec. It is designed to be GPIB/IEEE488 compatible (ie - the two interfaces can work together well) and it is the kind of protocol that perhaps you could implement in a simple 8 bit micro-controller without using too much resources.

http://www.hparchive.com/Journals/HPJ-1983-01.pdf
http://www.series80.org/PDFs/hp82169a.pdf

The maximum data rate of HPIL was 20KBytes/second. GPIB is 1MByte/second. With modern hardware, you probably could boost the speed of an HPIL-type interface, but 20KBytes/second is probably useful for most instrumental needs. HPIL has transformer isolation, so it is possible you could make an HPIL-type interface using Ethernet transformers.

As much as I like Ethernet, it isn't the interface I want to automatically add to all my micro projects. TCP stacks need a lot of resources, and TCP adapters are often much more expensive then the micro-controller circuit. I still would like something I can add automatically and that has an interface that can readily be recreated from a spec at any time in the future. Trying to read the many layers of the TCP/IP spec will drive anyone insane very quickly.

I do like the idea in having a range of adapters for instruments designed now (while the instrument drivers are still working) that would allow instruments to still communicate when the PC drivers are long dead.

If I had a go at designing my own personal cheap instrument bus, it would have to have adapters for Ethernet, USB and GPIB at minimum.

[tautech]

I really like the fact that Siglent has those GPIB adapters - I am guessing I probably do not like the price. For some reason, GPIB = $$$$.

My List RRP is US$155 + taxes if any

ATM they have USB A plugs.....I asked them to change them to USB B for connection to the B connectors that are normal at the rear of most modern TE so that the front USB A can remain free for USB sticks if required.

[amspire]

I really like the fact that Siglent has those GPIB adapters - I am guessing I probably do not like the price.

My List RRP is US$155 + taxes if any

Yup - a third the price of a digital oscilloscope for a very cheap microcontroller - perhaps two cheap micro's -  and a few interface ICs.

[nctnico]

IMHO $155 is very reasonable for such a box. It will be very hard to come up with a product for a similar price (if you want to make a living).

[amspire]

But that has always been the catch 22 with GPIB. It has always been expensive, so it has had a limited market and so it is expensive.

A company like Siglent could choose to break this cycle - if they wanted to. If they priced their DSO's the same way they price this adapter, the DSO's would start at $10,000 and the argument would be that the high prices is needed  - so few would be sold that they need the huge profit margin just to make a living.

If some company brought out a really solid $20 full spec gpib to ethernet or USB  adapter, they would sell a big quality.

[uncle_bob]

Hi

The real answer to GPIB and RS-232 is Ethernet. Sit down and price out the cable bill on a rack of GPIB gear. Now think about setting up a shop floor full of them. Next take a look at the device max numbers and start counting control cards. Toss in max cable lengths and you are off to RS-232 <-> GPIB adapter land (we once had a few hundred of those). This is a *very* expensive way to go.

Zip bang off to the Ethernet side. Cables cost next to nothing and the price is dropping. Need to connect up a few thousand devices? There are hub stacks that will do that. If you think they are expensive ... go back and check the GPIB prices.

Back in the dark ages, you needed an *entire* computer to run a rack full of gear. Storage speed, bus bandwidth, even stupid stuff like number of cards in the chassis all got you. Today, you can run the entire floor off of a single machine (compute / storage / bandwidth wise). You might not be smart to do that, but you could. Running a connection medium that will *let* you do that just makes sense. You now have the flexibility to hook everything up the way that you want to. You are not forced to do it a certain way to meet a bunch of cabling constraints.

That doesn't even get into the glories of stuff that came out in 1989 and still is in use. Yes the GPIB connects to a modern card. The custom software that makes the gizmo run still needs a DOS machine to chat with it. The custom board that does the non GPIB stuff plugs into an ESIA slot on a computer. All that pretty much died by 1995. The modern GPIB card isn't of much help on that system ....

Lots of Fun.

Bob