Is it possible to slow down the GPIB communications?

[megmond]

I am currently having problems communicating with a certain device by GPIB. The device randomly locks up when sending or receiving commands.

Talking to the manufacturer did not result in a solution, but apparently the problem is related to the speed with which the communications is run.

A small quote from the manufacturer:
"The reason of the problem is the speed of the commands. If customer is using delays, it will not help a lot. It slows down the speed of sending command after each other, but not the speed of the commands itself."

This indicates that I would need to slow down the GPIB communications. Is there any way I can do this? (By hardware, software, programmatically, etc.)

I a
m using LabVIEW 6.0.2 to develop my applications.

[cld]

Speed can be an issue here with some of the older instruments. Below are some steps you can try to slow the execution.
1) Run NI Spy in the background.
2) Change the board's default bus timing from 500ns to 350 us. This is done in MAX>>Devices & Interfaces>>Right Click on your Board>>Properties>>Configure>>Bus Timing (350ns)

Chris D
Applications Engineer
National Instruments

[megmond]

The GPIB board can be set to 2 us, 500 ns (default) or 350 ns. You specify 350 us first, which I assume is a mistake. However, 350 ns is less time than 500 ns, so wouldn't that make the execution go faster?

I don't know very much about the bus timings, but I would assume I need the 2us setting...?

In any case, I will have a play with the bus timing setting to see what happens.

[thp3]

I appear to be having the problem of the command overflowing the gpib buffer on an older device. The commands are coming in faster than the device can process them and some of the data appears to be truncated by the device. The previous answer only increases the delay before the DAV is set on the buss. It doesn't do anything about the how fast the data is presented on the buss. As my application is third party software I don't have the ability to change the length of strings sent to the device. I can't find a method of slowing down how fast the ibwrt comand places the data on the buss.

Regards

[madphoenix]

1) Running NI-SPY in the background (helped me troubleshoot the problem even though it wasn't a permanent fix
2) Increase bus timing to 2 us
3) Use programmatic delays (best solution)
4) I also found that when programming in LabVIEW on WIN 2000, optimizing for Background Services fixed some issues

http://zone.ni.com/devzone/conceptd.nsf/webmain/28A6979ECA9A0CAF862569050053D92D?opendocument

[GPIB_Guru]

First of all, this problem can only be associated to a broken instrument. The instrument itself controls how fast data is sent to it on the bus. That is the primary purpose of the interlocked 3-wire handshake.

If the device is unable to accept any more data (buffer-full), it can assert the NRFD line to indicate it is not ready for data. In fact, it is only allowed to deassert NRFD when it is actually ready for data.

For command transfers, the device is only supposed to deassert NDAC after it has accepted and processed the command byte on the bus.

If this device (or any other) is deasserting NRFD when it is not ready or NDAC when it has not processed a byte it is broken.

One other option available to help communicate to a b
roken instrument is to increase the cable lenght. This adds propegation delays that can sometimes "fix" a broken instrument. I have personally seen an 8-meter cable fix a similar problem. (The device got fancy and deasserted NRFD before it was ready, anticipating that the controller would take a "long" time to change the DIO lines. With new controllers and computers, the DIO lines were changed before the device latched the data, confusing the device.

Hope this helps...

[thp3]

I have no doubt the instrument is broken. I have 5 others in service in an automated test environment and they all exibit the behavior to some degree. These devices are over 15 years old and have an extremely poor GPIB implimentation. I do appreceiate your inputs as it clears up some handshaking questions. May have to get with the software vendor to see if they can configure the parallel poll to be sure the device is happy. The instrument isn't setting an error bit as they're pretty good about trapping them.

Thanks