Slow GPIB performance with NI-488.2 v2.3 driver

[CodedoC]

I recently upgraded the NI-GPIB 488.2 drivers to version 2.3 on a number of machines that were using various older driver versions ranging from 1.7 through 2.2.   Our GPIB cards are 2 to 4 years old.   When 2.3 was installed, we noticed an eormous performance hit on communications.  For example, even on our slowest (800MHz) computers, we are able to read from an Audio Precision S1 at its maximum reading reat of 32 readings per second.  This is normally a piece of cake for GPIB @ 1MB/s.  However, we now get only 10 to 16 readings per second.  When we go back to a prior GPIB driver version, the performance is back to normal.

Our newest instrument rack has a brand new GPIB+ card that came bundled with a CD containing GPIB driver v2.3 and it has the same problem.  Unfortunately, when we tried going back to versions 2.2 and 2.1, it will no work because the Measurement & Automation explorer crashes when coupled with this new card, but works fine on systems with older cards.  I cannot find Version 2.0 online anymore, and 1.7 does not even recognize this late-model GPIB+ card.

...So we're stuck with version 2.3 until 2.4 comes out with a fix.  For now, this is killing our production throughput.

My question is whether there is some low-level setting that perhaps version 2.3 changes which I might be able to manually override.   For example, defaulting to asychronous instead of synchronous communications, or something of the sort.  But as far as I can see, all communications settings are the same as found in versions 1.7 through 2.2, and NI-SPY shows no difference except in the timestamps.

Note that we're using NI-VISA 3.1, 3.1.1, and 3.2, (and other custom instrument drivers) under custom C++ test software--all with the same results.  Our racks contain the following instruments, all on the GPIB bus with the exception of our main power supply wich is controlled via a serial port:

1 Audio Precisions S1 (using custom drivers on top of NI-VISA)
3 Keithley 2400 source meters (using custom drivers on top of NI-VISA)
1 Keithley 2700 multi-meter (using their IVI B1.04 drivers)
1 IOtech 488/80A digital I/O (using custom drivers on top of NI-VISA)
1 GW Power Supply (serial communications through NI-VISA)
1 CPU with Windows XP installed.

Thanks,
CodedoC

[GPIB_Guru]

Version 2.4 is released. If the link doesn't work for you, go to ni.com, select drivers and updates, select current software versions, select GPIB, select version 2.4.

[CodedoC]

Wow, this is great!  It must have just been released because I checked for it a couple of days ago and it was not there yet unless I was looking in the wrong place.

So Thanks!  I'll give it a try and let everyone know if it solved the problem.  Hopefully, it's a result of the known problem with 2.3.

CodedoC

[GPIB_Guru]

Yes, this is a known issue with 2.3 that was fixed with 2.4.

[CodedoC]

Just tried 2.4 today.  Some things are better, like flashing the Keithley 2400s takes only about 1 minute instead of 10 minutes.  However, as soon as I make the first communication with the Audio Precision S1 device, the whole bus slows down to 1/2 to 1/3 the normal speed.

Again, GPIB versions 2.1 (and I think even 2.2) and earlier do not cause this problem, and if I put an older GPIB card in the unit, I get the same results with 2.3 and 2.4.  Unfortunately, the new GPIB+ card won't work with version 2.1.

Is there some mechanism where the bus slows down to what it thinks is the slowest instrument?  Is there a way to lock the bus speed?

Thanks,

CodedoC

[GPIB_Guru]

Since you do have a plus board, could you get a capture of transfers to the device. I would need everything captured, including timestamps. I would like to see where the delays are.

Thanks.

[CodedoC]

PROBLEM SOLVED!    Version 2.4 DID fix the problem after all.   I was having two problems, both affecting speed.  2.4 fixed one of them, but the other remained, so I assumed it was still the fault of the driver.  When I checked the older driver, I  must have used different test code that did not exhibit the problem.  So, the whole bus was actually not still slowing down as I had originally thought with version 2.4.  Only the AP System One device was still slow--but due to another problem with the reading rate being modified as a result of a coding bug.

Thanks for your help GPIB Guru.

CodedoC

[GPIB_Guru]

That is great news. I am glad everyting is working for you.

[Lasani]

Hi CodedoC

I see that you are using the IOtech Digital488/80A instrument in your rack. Do you have the driver for this box that you could share?

Thanks,

Lasani

[CodedoC]

I think IOtech may now have some drivers, but I'm not sure how flexible they are, and whether they follow any driver interface standard.

I wrote my own driver (a c-based DLL) which follows the basic IVI calling convention--most notably, the registration and initialization calls.  It does not rely directly on any IVI class driver, or other lower-level IVI drivers.  My driver speaks directly to another driver that I wrote which sits on top of NI-VISA.  One nice feature is that I support write caching, which can be useful in many coding situtations where you fight among the balances of code optimation, cohesion, and coupling.  I also support numerous levels of write granularity: bit/byte/dword or even multi-byte.  I can even set all 5 ports of a single channel using a single 64-bit integer--even on a 32-bit processor (although at the machine level, it's processesed in 32 bits on a 32-bit processor).  This makes setting relays using an ORing of defines for each of the 40 port pins quite simple. For example, I normally use a call such as the following:

IO80A_SetRelays (vi_IO80A_Ch0, R1 | R3 | R15 | R34 | R40);  Note: all non-included pins that are defined as outputs are automatically opened (logic low).

I also have a neat little utilty to drive the ports with the click of a mouse.  It supports all port configurations too.

FYI, I wrote similar drivers for the Keithley 2400 source meters and for the Audio Precision S1.

Now, to answer your question, and if this still sounds like what you need, I will have to check with my company if they wouldn't mind that I share this code.  It would mean that I have to share the lower-level NI-VISA interface code mentioned above.  Keep in mind that I do not code LabVIEW components, but LabVIEW should have no problem using my DLL.  I may also be available for contract hire if it is not for work in the semiconductor industry.

What is your application and what are your requirements?

CodedoC