Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

GPIB Writing Succeeds, Reading Fails

Operating System: Windows 2000 SP4
NI-488.2: 2.3
Controller: PCI-GPIB+
Symptom: Writing to instruments is successful, reading is not

Example using frequency synthesizer, the instrument uses only EOI to terminate reads and writes. The following NI Spy output shows a successful setting of frequency to 3000HZ and then a time-out when interrogating the current frequency setting. On receiving the ibrd command the instrument "Listen" light turns off, the "Talk" light turns on but no data is received.

NI Spy transcript:
1. ibwrt(UD0, "FR3000HZ", 8 (0x8))
Process ID: 0x00000160 Thread ID: 0x0000073C
Start Time: 12:42:43.096 Call Duration: 00:00:00.020
ibsta: 0x100 iberr: 0 ibcntl: 8(0x8)
2. ibwrt(UD0, "IFR", 3 (0x3))
Process ID: 0x00000160 Thread ID: 0x0000073C
Start Time: 12:45:36.600 Call Duration: 00:00:00.000
ibsta: 0x100 iberr: 0 ibcntl: 3(0x3)
> 3. ibrd(UD0, "", 2000 (0x7D0))
> Process ID: 0x00000160 Thread ID: 0x0000073C
> Start Time: 12:45:54.639 Call Duration: 00:00:16.786
> ibsta: 0xc100 iberr: 6 ibcntl: 0(0x0)

The GPIB+ analyzer record is (instrument is at address 18):
TA0 UNL LA18
FR3000HZ END IFR END
UNL LA0 TA18

Similar results with at least one other instrument.
0 Kudos
Message 1 of 7
(4,652 Views)
Lemuel,

Are you sure that the instrument is supposed to respond to the "IFR" command? Many query commands end with "?", should you have a question mark at the end of this command? You'll need to check your instrument's manual to confirm this.

This sounds like everything is going fine with NI-488.2 and your GPIB interface, but the instrument has nothing to say. The "talk" light coming on on the instrument usually just means that it is addressed to talk (which it is: the analyzer reports TA18 as a bus command), but that light turning on doesn't necessarily mean that the instrument has data available to send to the controller.

Hope this helps.

Scott B.
GPIB SW
National Instruments
0 Kudos
Message 2 of 7
(4,635 Views)
"IFR" is the correct command.
0 Kudos
Message 3 of 7
(4,633 Views)
Additional info: I connected the instrument to an ancient Win95 system with AT-GPIB/TNT installed running NI488.2 Version 1.6. The instrument immediately responds to the "IFR" query with the current frequency setting. Both the working and non-working controller systems have the same EOI/EOS settings.

Using the Win95 system is not an option...
0 Kudos
Message 4 of 7
(4,627 Views)

Lemuel,

There must be something different happening between W95 and W2K. There are no reported cases of the 2.3 driver failing to do something so common. Since you do have an analyzer card, however, we can get into the bus and see what the differences are. First, let's get a capture of the W95 machine "working case". Connect the windows 95 machine to the instrument like normal, but then also daisy-chain the PCI-GPIB+ analyzer card in the other computer onto the bus. Make sure that MAX and all other programs are closed, and then run the GPIB analyzer application while you do the IFR command from the 95 machine. Make sure you have the analyzer app set to these settings [link removed; article no longer available]. It should work like normal. Save that capture.

Next, connect your PCI-GPIB+ board and the instrument together (without the W95 machine). Run the same capture and save that as the failing case. Look over them to see if you can find any major differences (the timing will be slightly different, but that shouldn't affect much). If you'd like to post the 2 captures here, I'll take a look at them.

Thanks,
Scott B.
GPIB Software
National Instruments

Message 5 of 7
(4,618 Views)
Given that you used the correct method of terminating Reads and Writes. The difference between different OS is only timing. You can check if the Win95 system takes a longer time to finish reading than the "timeout" value you specified in your code running on Win2000. I suspect that somehow the older OS/driver slows down the communication which end up giving the instrument enough time to respond. Scott is right that we can find this out by looking at the capture files.
0 Kudos
Message 6 of 7
(4,609 Views)
Even more info: When I remove the frequency synthesizer from the equipment rack and attach to the Win95 controller data can be read and written. I re-install the synthesizer in the rack then neither the Win95 or Win2000 controller can read data from any instrument when attached to the GPIB bus connecting all the devices...

[MUCH later....]

There is one instrument which, when turned on, prevents either controller from reading data from any instrument on the bus. Not clear whether this is a cable or instrument problem, but the Win2000 GPIB+/NI488.2 installation is not the problem. Thanks!
0 Kudos
Message 7 of 7
(4,594 Views)