Slow GPIB fixed by NI Spy

[flipflop]

I am duplicating a test station.  On the original PC, a certain GPIB data upload takes about 2 seconds.  On the new PC, the GPIB upload takes 5-10 seconds.  Oddly, turning on GPIB communication capture using NI Spy speeds that data upload to 1 second. 

Equipment: PCI-GPIB, LabWindows version 6.0, Windows NT system (We're stuck with an NT-specific driver for the time being.)

Other observation:  The new PC uses interrupt 9 for the PCI-GPIB card and another card.  This is not expected to be a problem.

The goal is to fix the slow GPIB communication.

[Highland_Controls]

What device are you getting the data from?  Is it old, pre-488.2? 

[flipflop]

The instrument is an Agilent 3458A DVM.  In the instrument documentation, it seems to support IEEE-488.2 massages.  However, I've noticed that the instrument doesn't always respond to the exact IEEE-488.2 format.  That being said, I doubt that the 3458A is the problem.  The same 3458A transfers data at different speeds dependent on the PC and whether NI Spy is capturing communication in the background.  It seems to be a driver setup problem.

[Zach-H]

So, you have this exact same setup working on the original PC? But for some reason the duplicate station you're making is slow? 

What differences are there between the machines? Are you using interrupt 9 on the original as you described on the new machine?

[flipflop]

On the original PC, the PCI-GPIB card uses interrupt 9, and I believe it has exclusive use.  On the slower PC, interrupt 9 is used by some other card.  Unfortunately, I could not find a way to change the PCI-GPIB interrupt; even by reloading the software.  Still there remains the curious question of why an active NI Spy capture makes the GPIB communication fast.  NI Spy seems unaffected by the interrupt.

[Albert.Geven]

Often a race condition can look to be solved by the debug lamp or another change of speed like NI-Spy.

So probably some parallel accesses are going on.

I also don't believe that the interrupt is the problem although in essence it is a bad hardware design to use edge triggered interupts. 

[flipflop]

This leads to two questions...
How could I detect and correct parallel accesses?
What is the "debug lamp"?  (Remember, I work with LabWindows CVI.)

[Zach-H]

There are a few ways to correct parallel access. If you search "wait" in the help directory. My 15th option is about "CmtWaitForThreadPoolFunctionCompletionEx" which looks fairly promising. There is also a lock Session article, but I am on a much newer version of labwindows. Check out what is available to you in 6.0. 

The "debug lamp" is the highlight execution button in LabVIEW. It is similar to continuously stepping through lines of code during debugging. It slows the program flow enough to show the user where and when things in the graphical program occur. 

[flipflop]

I have used the thread functions that are available in CVI version 6.0. These functions only pertain if the program is using the LabWindows multithreading utilities.  I am not using them in this particular program.
The CmtWaitForThreadPoolFunctionCompletionEx() version, itself, is not available. 

[Zach-H]

So, the NI Spy leads me to think that you're seeing race conditions as Albert mentioned. That being said, you're not using threads. So, my logical progression is to think that your interrupt triggering two devices is causing the race conditions. Is the second device active while you're carrying out the GPIB? I know you said you couldn't change the interrupt, but is there a way for you to change the priority of the interrupt? If you were to set the GPIB to high priority, it would default to carrying out the GPIB first then the other card second. Other question, how necessary is the other card?