Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

clarifying GPIB cable length spec

I was wondering if anybody knew the exact requirements on cable length in the GPIB spec.  Everyone agrees that the total cable length cannot exceed 20m, but the second requirement is less clear.  I've seen it given as no more than 2m between devices, but this can't be right as you can buy 8m cables!  I've also seen it as max length=min(20m,2m*N) where N is the number of devices (including the controller...?).  That's better, but it would mean that adding more devices relaxes the spec.  Shouldn't adding more load reduce the amount of allowable cable?

Also, is the maximum cable length between any two points an important variable, or do the specs only concern load and not delay?

If the spec is violated, what is the expected result?  Data errors?  Reduced data rate?

Thanks for any insight,

Alex Gerdemann
University of Ilinois Urbana-Champaign
0 Kudos
Message 1 of 10
(8,035 Views)
This is from the NI-488.2 help file:

Configuration Requirements

To achieve the high data transfer rate that the GPIB was designed for, you must limit the number of devices on the bus and the physical distance between devices. The following restrictions are typical:

  • A maximum separation of 4 m between any two devices and an average separation of 2 m over the entire bus.
  • A maximum total cable length of 20 m.
  • A maximum of 15 devices connected to each bus, with at least two-thirds powered on.
For high-speed operation, the following restrictions apply:
  • All devices in the system must be powered on.
  • Cable lengths must be as short as possible with up to a maximum of 15 m of cable for each system.
  • There must be at least one equivalent device load per meter of cable.

If you want to exceed these limitations, you can use a bus extender to increase the cable length or a bus expander to increase the number of device loads. You can order bus extenders and expanders from National Instruments.

8 m cables seem to work, but they technically violate the IEEE spec.  If you are way off (I've seen 15 m cables), you can expect data corruption, and possibly slower performance (I would think the handshaking lines can take longer to settle?).
Message 2 of 10
(8,024 Views)
>> I was wondering if anybody knew the exact requirements on cable length in the GPIB spec.  Everyone agrees that the total cable length cannot exceed 20m, but the second requirement is less clear.  I've seen it given as no more than 2m between devices, but this can't be right as you can buy 8m cables!  I've also seen it as max length=min(20m,2m*N) where N is the number of devices (including the controller...?).  That's better, but it would mean that adding more devices relaxes the spec.  Shouldn't adding more load reduce the amount of allowable cable?

Section 6.4 of IEEE 488.1 states the maximum cable length shall be the lesser of 2x the number of devices or 20m. The spec gives a warning about using cable lengths longer than 4m. The loading per unit distance requirements are given in the Data Rate Consideration section (5.2), and those are given as guidance and not requirements. That is where the 1 load per 2m of cable comes from. There are additional requirements for HS488 systems, but I don't have that spec handy.

An 8m cable does not violate the spec as you could have 6 devices connected with 4 - 0.2m cables and 1 - 8m cable. This does not violate the overall requirement of 12m (6 devices * 2m/device). It does violate the guidance of 2m or less between devices.


>>Also, is the maximum cable length between any two points an important variable, or do the specs only concern load and not delay?

IEEE 488.1 uses an asynchronous handshake protocol so electrical propagation time (delay) is not significant relative to latency.


>>If the spec is violated, what is the expected result?  Data errors?  Reduced data rate?
If you were to violate any of the specs by a small margin you would probably not see any errors. If you were to violate the spec by a larger margin you may see data corruption. Data integrity is not garaunteed by the specification as with some other busses, meaning that if you get data corruption you will not likely get any error notification. Data errors will likely be difficult to detect, especially if the data is arbitrary binary-type data. Also, the data rate will not be altered if bus errors occur. I have never heard of a data error occuring because of excessive cable lengths, but it could happen.


If you want to describe your system I could make some specific observations and suggestions.



Message 3 of 10
(8,025 Views)
Thanks for the information.

Our setup consists of a stack of nine pieces of equipment controlled by a computer.  The equipment must be nearby a couple of probe stations which doesn't leave room for the computer.  So, right now we have a six meter cable (made out of a 2m and 4m cable) that runs across the floor.  The equipment is connected with a combination of 0.5m and 1m cables.  We've never detected any problems with this setup.  However, to clean things up, I'd like to run the cable to the computer through the ceiling, but that will require maybe a 10m cable.  I guess if we ignore the guidance, and only adhere to the strict rules this will not violate the spec.  However, any suggestions would be appreciated.

The "correct" solution, I suppose, would be to get a ethernet to GPIB interface, but as we are a university lab, the $1000 is a bit more than we'd like to pay.

-Alex
0 Kudos
Message 4 of 10
(7,996 Views)
The setup with the 10m cable should work. You could write a simple test program that does some reads and writes and checks the data you read against the expected data, if you're concerned about it.

Adding cables and devices actually improves signal integrity, because it adds capacitance. Adding capacitance dampens overshoot and ringing because it slows the edge rate. Of course there is a point where adding more cables/loads will cause a problem. A slower edge rate also means a slower transfer rate, but only slightly.


Message 5 of 10
(7,983 Views)
This is a bit of a side question but along the same lines.  I have a legacy application that I'm working on right now.  There are between 16 and 20 devices on the bus and while the maximum cable length between instruments is not a problem, I think the 20 meter maximum has been met.  I'm looking at ways to improve the setup and I'm wondering if I could split the number of instruments in half by using two USB GPIB controllers - this would eliminate almost 8 meters of cabling and bring the number of instruments per bus comfortably below 14.

I guess I just wanted reassurance that this was a legitimate thing to do and when talking of a 'bus', we are referring to a single controller/card and connected equipment.

Many thanks,

Chris
0 Kudos
Message 6 of 10
(7,466 Views)
You could split the busses as you described and use a different GPIB controller for each bus. Note that this would require a software change.

You could also buy a GPIB extender which would not require a change to software.

Then there's the old adage - If it ain't broke don't fix it. It's always tempting to "fix" things but doing so can introduce new issues.

You are correct that referring to a bus usually means a single, electrically connected GPIB system, typically with one controller. So a GPIB-USB connected to 5 instruments through GPIB cables would be considered one bus. If you broke that up and used two different GPIB-USBs, one with 2 instruments and one with 3 instruments, and no GPIB cable connection between the two, you would typically say you had two different busses.

The above cases refer to logical and electrical busses as the same. With our extenders things are a little different. When using an extender you break up a single bus into two different electrical segments but it is still the same logical bus. Each side of the extender can be treated electrically as a separate bus but logically there is still one system controller and there can't be any address conflicts.

0 Kudos
Message 7 of 10
(7,456 Views)
Thanks very much for the clarification.  As you say, the bus extender would be the least invasive method of approaching things.  If I were to use it, would that mean that the potential of having 20 instruments would not be an issue?

Thanks again,

Chris
0 Kudos
Message 8 of 10
(7,445 Views)
Having 20 instruments would not be a problem as long as it is configured correctly. If you go this route you should consider the GPIB-120B http://sine.ni.com/nips/cds/view/p/lang/en/nid/203221

The online documention for that product has more details.

0 Kudos
Message 9 of 10
(7,439 Views)
Thanks - I did not realize that this was an actual 'expander' until opening the link - that was a bit of a daft question!!  Very much appreciated...
0 Kudos
Message 10 of 10
(7,436 Views)