GPIB, RS-232, or USB?

[aeroAggie]

I would like to purchase a programmable power supplies for our lab. Some power supplies have an RS-232 port, others have a GPIB port, While other still have a USB port and an RS-232 or GPIB port.

Is one protocol better than the others? If not, what are the advantages of each protocol? And why did NathanT recommend GPIB over RS-232 in this thread?

Thanks!

[crossrulz · Accepted solution]

You should give this article a good read: Instrument Bus Performance – Making Sense of Competing Bus Technologies for Instrument Control

Of the 3 buses you mentioned, I would use GPIB.  But my personal preference is Ethernet.

Power supplies are just slow by nature, so I would not worry about bus speeds.

GPIB is expandable (can have multiple on the same bus).  RS-232 and USB you are stuck with a single power supply per bus.  Granted, with USB, you could use a USB hub.  If you go Ethernet, just buy a decent network switch.

However, GPIB is probably the most expensive.  You have to buy a controller card and cables, all of which are not cheap.  But the bus is solid.

As far as software is concerned, all the buses send and recieve the same data.  So you just need to use VISA when creating any software and then you just need to change the initialization if you decide to later change which bus you want to use.

[Dennis_Knutson]

I like Ethernet as well but use a dedicated nic on the pc to connect. This could be connected directly to a single instrument or the switch if you have multiple instruments. USB physical connections are not very robust so you should use something to protect them from accidental removal such as rack mounting the pc and instrument. Windows default settings will also power down USB connections after a time so that is a setting that would need to be changed. GPIB's only downside is the cost of the controller.

[JÞB]

I'll dissent.  Funny, I usually say "I'll Chime in."

And esspecially with two pillars of the community.

Power supplies (as noted above) generally operate a 0Hz.... really slow.

The controll bus is generally unimportant to your experiment, the PS Specifications for stability, accuracy, repeatability, thermal drift Ad Nausium... should be your primary concern!  Can the instrument power your experiment?  When and if you've read the specs then and ony then should you consider IN ORDER:

• Availability..(is the manufacturer established?  Can they supply the number you need? Is the manual readable? what are the calibration facilities you use ready to service? will the device go obsolete durring the projets lifetime?
• Cost (not price cost...is there a driver...is it any good.. how many manhours would it take to develope one?)
• Exchangeability...(do I have a bunch of different units I commonly use that I can swap in without changing code? Think IVI but think device compatability too!)
• Control bus

Given all those prerequisites.  Ethernet is nice if you have a lot of instruments at long range that are all capable of playing nice on the same network.  GPIB is very cost effective for multiple devices nearby (a CBA should be done. hanging a GPIB bus for 1 device is costly, if you have more devices than serial or eithernet ports available GPIB is cost effective. COST again what supporting hardware will you need?  Serial RS-232 is useful if the protocol is modern and you want one bus per device. Multidrop Serial RS 422 or RS 485 are nice too  CAVEATE did you know the RS stands for "Recommended Standard?"  I'd read the manual carefully first!

USB can be very useful if you read the FAQs (search for it I've quoted it alot!) however, its not as cheep as usually thought!

[aeroAggie]

Thanks Jeff, I appreciate your input. I haven't neglected learning the other properties of power supplies. I just wanted to learn the advantages and disadvantages of the PC interfaces from NI users.

Regarding the factors you mentioned,

1. Availability: I'm leaning towards BK Precision. They're expensive, but it looks like all of their instruments have drivers for LabVIEW, which is how I aim to control my PSU.
2. Cost: This is just the pure and simple price of a PSU. I'm an aerospace major, so I'm not going to develop drivers by myself.
3. Exchangeability: I hadn't thought of this. I assume my LabVIEW code will just work if I have the LV driver for whatever device I'm using--am I wrong? And what is IVI?

I'm going to work in a very short-range environment (my PC, a PSU, and my experiment all on one desk), so I'm leaning towards USB for convenience. However, since I will ultimately end up controlling multiple PSUs, I may just set up a GPIB control system--which begs the question: what is a CBA?

[crossrulz]

---

aeroAggie wrote:  However, since I will ultimately end up controlling multiple PSUs, I may just set up a GPIB control system--which begs the question: what is a CBA?

---

CBA = Cost Benefit Analysis.  Basically, will you get your money's worth out of the product.

Since you are controlling many, I would avoid the USB.  GPIB is a good choice in that situation.  Your drivers should not care which bus type you use since I think they use VISA.

[aeroAggie]

And here I thought it was something fancy like Controller Bus Acccss 
 

[Dennis_Knutson]

A brief description of IVI:

IVI stands for Interchangeable Virtual Instruments. VISA abstracts the physical connection and IVI abstracts the actual instrument. There are several classes of instruments such as DMM, power supply, oscilloscope, etc. The IVI Foundation members have defined a set off functions that is common to all instruments in its class. There is an instrument specific driver that takes the common functions and converts to the commands that are unique to the instrument. If your program uses nothing but the class functions, you can replace the existing physical instrument with a different make and model without any changes to your code. There are other features such as simulation and state caching. Some vendors only provide IVI drivers since they can be used in just about any programming environment and they don't bother to create a second, native LabVIEW driver.