GPIB connection works better when NI Spy Capture is ON ???

[TDF]

Hello,

We've got a Antenna measurement System with a recevier, an antenna positionning system and a PC, all linked with a GPIB interface.

We have many problems, bugs, low speed positionning, error in acquisition data...certainly due to GPIB parameters.

When NI SPY Capture is ON before starting our system, everything is OK !

If NI Spy Capture is started after our system, the bugs go on.

How can NI Spy improve the GPIB connection between our components?

Buffer size? Speed?

Thanks for help,

Laurent

[Albert.Geven]

This must be speed, how is your cabling, at most 2m between two instruments and at least half of them powered on?

[TDF]

We currently use two cables :

- 2m cable between the receiver and the PC

- 1m cable between the PC and the Antenna Positionning System.

Do you mean that NI Spy decreases the GPIB interface speed when it is ON ?

If so, how can we manually decrease the GPIB speed without starting NI Spy ?

Thanks,

Laurent

[Brian_Beal]

Yes, NI Spy slows down communications.  You can change the speed of your GPIB card through MAX.  How old are the GPIB instruments?  If they are based in IEEE 488-1978, then even the slowest board setting may be too fast.  You can always add a small (10mS or so) delay after each read and write.

[Albert.Geven]

What you can do is in the gpib-pci card properties change the speed to 2uS for handshaking.

I can't give an example (no gpib at home) but that is one of the few settings that remain from the old days.

Do this from MAX/devices and interfaces/pci-gpib/properties (the last one by right mouse click) 

[Collin M]

This is a subtle point, but although it is true that NI-Spy will slow down an application it does so at the software level not the hardware level. The GPIB state machines inside the GPIB controller ASIC don't "know" NI-Spy is running and run at the same speed regardless of the state of NI-Spy. It is true that altering the T1 setting will alter the speed but not in the same way the NI-Spy does.

I don't know exactly how NI-Spy works, but it seems to add delay proportional to the number of driver/API calls, not the number of bytes transferred. The overall slowdown caused by NI-Spy should be the same for a transfer of 100 bytes as a transfer of 100,000 bytes, assuming the same number of driver/API calls for each transfer.

I doubt you are seeing a problem with cabling or the T1 delay (bus speed) because these are unaffected by the state of NI-Spy. It is likely that NI-Spy is adding some delay that masks some bug in your application.

[Albert.Geven]

You are absolutely right Colin, It must be something in the software or (but I don't believe the instrument is that old) something in between the commands.
10 years ago we found an old parameter analyzer that needed a delay between two stb reads, otherwise the machine was so busy processing the stb that it forgot to measure. But probabbly a race condition in LabVIEW is "solved" by the Spy.

Did you wire the error-out from the previous call nicely to the error-in of the next or did you not wire the error IO?
This is the best way to prevent raceconditions.

[TDF]

Thanks for your answers.

The problems remain the same by adjusting the Time Speed to the highest time value (2usec), and changing cable length have no effect too.

So the problem could be caused by the acquisition software itself?

I'll ask the programmer about what he thinks about that,

Thanks,

Laurent