LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Having trouble reading HPIB instrument consistently in a GPIB system

I have a couple HP 5328A Universal Counters that I am trying to communicate with. At the moment i am simply using interactive control (ibic), but will eventually be using LabVIEW 7 to build a soft front panel. The problem is that reading from the machine is very inconsistent. I can get a reading if I make about 20-30 ibrd() calls while shifting the GPIB cable around in the back of the counter. I get the same behavior from two different counters so I find it hard to believe the HPIB option on the instrument is at fault. The cable has been tested on another instrument and worked flawlessly. There is no sign of any damage or corrosion to the connections.

Another point that may help is that once a
succesful read is made, each succesive read is also successful, even if i keep jiggling the connection. However, I cannot write to the instrument a second time (using ibwrt()). When I do try a write operation after a successful read, I get an ENOL (No Listeners) error. Yet another source of frustration is the even more inconsistent behavior of the RQS bit and the status register of the instrument. I have seen the RQS bit generated as well as the correct status register contents (used ibrsp(): serial poll) when the reads are successful, but only once or twice. I have not even been able to get this status requesting behavior on 10% of my successful reads.

Here are my specs:
NI PCI-GPIB card
WinNT
MAX 3
VISA 3
instrument vintage: ~1980

I'm stuck. Any input is appreciated.
Thanks,
Chris
0 Kudos
Message 1 of 9
(3,025 Views)
Hi Chris,

sounds a little bit like LabWindows - I have no idea how it works. I have the impression, that you do not fulfill the protocol, that is needed for this instrument (missing EOL or something like that).
I found a LabVIEW driver for HP 53181A RF-frequ.counter at NI website. Maybe you should try to use it ( or adapt ) for your instrument. You do not need to invent the wheel again....

regards
wha
0 Kudos
Message 2 of 9
(3,025 Views)
Can you post a your ibic commands? Just the initialization, the original ibwrt and then the results of a successful ibrd as well as one that isn't successful. That might get some more eyes looking at what you're doing.
An
0 Kudos
Message 3 of 9
(3,025 Views)
This is the sequence I usually use:

ibclr
ibwrt "PT"
ibrd 17

All that is usually returned is CMPL for the clear and write and ERR, TIMO, CMPL for the read.

The "P" initializes the device into a default state and the "T" triggers it.

Some more inconsistent behavior since original post:
I turned the instrument on this morning with ibic still running and set up to connect to the counter. I issued an ibclr() command and the RQS bit was set properly. The contents of the status register where also correct when serial polled (ibrsp()). I next tried an ibrd(), which failed due to timeout. After this the RQS bit would not set, the status register did not get set properly, and the reads were all unsuccessful.

Any more thoughts?
Thanks for the help
,
Chris
0 Kudos
Message 4 of 9
(3,025 Views)
I have tried writing the EOS char along with each write as well as making sure the EOS char is the correct one for the device. Nothing seems to be affecting the device's behavior.

Chris
0 Kudos
Message 5 of 9
(3,025 Views)
Despite the cable working on another instrument, I'd replace it anyway - at least
as an experiment. Cables can break.

Also make sure that you are not exceeding total cable lenghts in your system,
maximum instruments, and all connected instruments are turned on.

Les.Hammer@CompleteTest.com
0 Kudos
Message 6 of 9
(3,025 Views)
I have since tried another cable, but to no avail. The cable is about one meter and there is only one device in the system.

thanks for the input,
Chris
0 Kudos
Message 7 of 9
(3,024 Views)
Chris,

When you trigger the device does it continually generate data you can read? From your original description it sounded like you could keep reading and so that's the impression I have. If that's the case you may not be able to write to the device since it's busy with that operation.

One thing to try is to follow the ibic sequence from this page: http://www.ni.com/support/gpib/max/ibic.htm Wondering if calling ibsic etc might help.

The other thing I would try is to send just an id query command and see if you can send that and get that working. If that works then the issue is with the PT command sequence.

Also, if you turn off the instrument and then issue your command sequence for the first time does it always work or is that in
termittent ... is there any pattern to when you get TIMO versus CMPL?

Regards,
Kamran
An
0 Kudos
Message 8 of 9
(3,025 Views)
Kamran,

When I trigger the device, it will only output once on all functions except one. The one function that works is a check function that outputs 10 all the time. Everything else needs to be reinitialized and a hard reset needs to be performed. I tried the sequence of commands in the link which gave me a little more insight into initializing the machine, however it did not do much for solving my problem.

This is a HPIB device and does not support ID queries to my knowledge. The PT sequence is a problem I have found, but cannot figure out why because that is what the manual says the instrument will understand. For some reason a single asterisk will give an output, but only once. Also, the only command so far that is generatin
g a service request are the addressing commands.

Anyway, I have been talking with Agilent and hopefully I will post what got this thing working for your interest. Thanks for the suggestions.

Chris
0 Kudos
Message 9 of 9
(3,025 Views)