11-18-2011 04:05 PM
Do you know how to set the GPIB interrupt to a higher priority?
(Next week I'm considering installing an ISA-slot GPIB card. I may be able to control the interrupt for that card.)
11-21-2011 09:10 AM
This is an interesting problem you have, since the expected behavior of enabling NI-Spy would usually be a slight slowdown.
It seems unlikely to me that the problem has anything to do with the interrupts. PCI devices routinely share interrupts. If the problem is slow interrupts, it wouldn't speed up with NI-Spy enabled. Given your current situation, the best way to diagnose what is happening would be with a GPIB Analyzer, such as the PCI-GPIB+. This would make it possible to determine what behaves differently when NI-Spy is enabled or disabled.
It is unfortunate that you have to use Windows NT, as that will prevent you from using any current NI-488.2 drivers. What version of NI-488.2 do you have installed on the computer?
-Jason S.
11-21-2011 03:56 PM - edited 11-21-2011 03:56 PM
Well, upon further reviewing interrupt #9 it appears that it is already a priority interrupt set by the operating system. I can't find anything about a low priority function.
11-22-2011 07:50 AM
There are a few other things I may investigate...
I'm going to change the PCI-GPIB slot. (I don't expect this to make a difference.)
The HP3458A is an older style driver that uses ibrd() and ibwrite() calls. When I added code to read the waveforms, I left the driver alone for political purposes, and used a Send() to write some of the new get-waveform-data-point instructions. The Send() seems to be the slow instruction.
I also noticed that NI Spy has it's own set of .DLL files. Perhaps NI Spy is using different IEEE-488 driver code than LabWindows CVI.
11-22-2011 09:10 AM
The NI-488.2 driver will call into NI-Spy to log its function calls. This causes a small amount of overhead for the driver, but the driver is the same whether NI-Spy is running or not.
I think you should pursue replacing Send with ibwrt, to see if it improves the speed of your application.
04-05-2019 04:07 PM
I know this is an older thread, but I had a similar issue with two identical test stations where one station was 3-7X slower than the other. I swapped out GPIB controllers, swapped equipment between the two stations, swapped PC's, nothing worked. Finally, on the slow station, I disconnected and reconnected all GPIB cabling into more of a "chain" instead the "star" pattern that it was originally configured in. This fixed the problem.
So before doing all this stuff to fix a GPIB speed issue, I'd verify your GPIB communication is in a serial configuration rather than lots of smaller branches.
04-22-2019 02:59 PM
Did you verify the impedance of each cable? Were you certain that all of the shields were working properly? Were all of the connections/seatings verified prior to removal? Did you attempt to remove each cable independently to verify functionality? It sounds as if you just ripped everything apart and threw it back together differently and it worked - see, problem solved. Although it may be working, that doesn't mean that is the solution. You may have had a cable that was twisted and lost its shield or another wire that may have caused reflections in the line leading to the added delays. Your solution works in your case; however, it is not a universal solution.