Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

Slow GPIB fixed by NI Spy

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.)

0 Kudos
Message 11 of 17
(1,497 Views)

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.

0 Kudos
Message 12 of 17
(1,485 Views)

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. 

Applications Engineer
National Instruments
CLD Certified
0 Kudos
Message 13 of 17
(1,473 Views)

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.

0 Kudos
Message 14 of 17
(1,461 Views)

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.

0 Kudos
Message 15 of 17
(1,459 Views)

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.

0 Kudos
Message 16 of 17
(974 Views)

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. 

Help the Community (and future reviewers) by marking posts as follows:
If it helped - KUDOS
If it answers the issue - SOLUTION
Message 17 of 17
(952 Views)