Intermittant response from spectrum analyzer

[vivlund]

I have LabVIEW 8.2, NI 488 v.52. I am having problems talking to an old HP 8568A spectrum analyzer. 

I can write to it OK, but reads are intermittant. 

It takes a carriage return on the end of commands. On some reads, the response is fine using VISA in LabVIEW or using the NI-488.2 communicator, but on other reads, I get a timeout error EABO.

The funny thing is, the response is actually there from the analyzer...It's like VISA or LabVIEW isn't seeing the response every time.  And this happnes with every command written to the analyzer that generates a response..

Here is the NI-SPY capture where the first read went perfectly:

2.  ibrd(UD0, "-13.50..", 2000 (0x7D0))
Process ID: 0x000008A8         Thread ID: 0x00000F1C
Start Time: 22:10:05.664       Call Duration 00:00:00.010
ibsta: 0x2900       iberr: 0             ibcntl: 8(0x8)

Here is another where the read timed out, but the correct response was actually read:

>8.  ibrd(UD0, "-13.50..", 2000 (0x7D0))
>Process ID: 0x000008A8         Thread ID: 0x00000F1C
>Start Time: 22:11:41.672       Call Duration 00:00:16.774
>ibsta: 0xc900       iberr: 6             ibcntl: 8(0x8)


Thanks in advance for your time and help.


Viv

[Krista H]

Hi Viv,

Have you tried replicating this issue in Measurement & Automation Explorer. If you could run NI-Spy and send in the spy file while you get the issue in Measurement & Automation Explorer that would be really helpful. I need to see the actuall file to be able to trouble shoot. Thanks

[tyang]

Hi,

I am having the same problem; Did you ever find an answer to this? The return status is 0x2900 on a successful read; which indicates -- 0010 1001 0000 0000

bit 13: EOI or EOS Detected

bit 8: Operation Completed

but bit 11: ???

Using a different instrument that does not have this problem, the return status of a successful read is 0x2100. (which does not have bit 9 set). Perhaps this can clue you guys in on whats going on?

Any help would be appreciated.

Tony

Message Edited by tyang on 10-30-2007 03:24 PM

Message Edited by tyang on 10-30-2007 03:25 PM

[tyang]

Also, if it helps - the buggy instrument also reutrns (status) 0x0900 on a write comamnd (always succesful?), whereas the working one returns a 0x0100.

[tyang]

Attached is the NI SPY capture;

The first 4 captures are sent to the instrument that doesn't have any issues communicating and the subsequent captures are the intermittent responses from the buggy instrument.

[vivlund]

Hi tyang,

We were never able to get a true resolution.... We found that the "B" version of the analyzer was different than the "A" version. 

On the HP8568A, we had to end each command where data was to be read back from the machine in a "/r" carriage return.

We also had to wait 5 seconds between successive commands that read data from the HP8568A.

On the HP8568B, it would not work when a command to read data was terminated with a carriage return.  The "/r" had to be removed.

Hope this helps.

Viv

[vivlund]

ALSO:

I forgot to mention that we ended up with the HP8568A having to specify the to specify the number of characters that were read on each read request in the VISA Read VI due to the 8586A’s not sending an EOI.

The read request would time out if we requested the read to end on an EOS character. 

Viv

[tyang]

Alright, we figured out the problem, but this may not have any relevance with the problem your encountering.

Because the instrument I am using is the last link of the GPIB daisychain, there seemed to be some distortion in the remote communication it could receive (possibly signal reflection from the end?) When I attached another GPIB stub (not connected to any instruments), all instructions I sent worked successfully, (both write and read).

Quite an odd error, with an unexpected solution.

Successful reads and writes are still 0x2900 and 0x0900 though.

[tyang]

To get a better picture of what im talking about, here's a very crude diagram:

[B] has problems with query commands so the solution becomes

Computer [X]

Instruments [O]

Buggy Instrument [B]

==== GPIB connection

Initial setup: [X]==[O]=[O]=[O]=[B]

Fixed setup: [X]==[O]=[O]=[O]=[B]=

the last = represents another GPIB cable that is a stub, with no instrument attached.

Hope that helps..