NI PCI-GPIB vs. HP 3488A SCU

[AllanH]

We have three HP 3488A SCUs on the same bus that have worked fine as part of an MCS for over a decade. An upgrade has changed the controller from an HP-UX machine to a Win2000 PC using an NI PCI-GPIB card (driver version 1.70). We are now finding that all three SCUs reset themselves simultaneously several times per day. We have done many things to narrow the problem down and are at the point of possibly concluding that the NI controller card is simply not fully compatible with these old 3488A units.

If anyone has any experience related to this, we would appreciate hearing from you. We would value some advice on proper configuration parameters for this scenario.

[Methis Elddir]

On Fri, 27 Feb 2004 10:25:03 -0600, AllanH wrote:

> We have three HP 3488A SCUs on the same bus that have worked fine as part
> of an MCS for over a decade. An upgrade has changed the controller from
> an HP-UX machine to a Win2000 PC using an NI PCI-GPIB card (driver version
> 1.70). We are now finding that all three SCUs reset themselves
> simultaneously several times per day. We have done many things to narrow
> the problem down and are at the point of possibly concluding that the NI
> controller card is simply not fully compatible with these old 3488A units.
>
> If anyone has any experience related to this, we would appreciate hearing
> from you. We would value some advice on proper configuration parameters
> for this scenario.

I have an HP3488A.
I use it with a NI-PCI-GPIB/+ controller. The only
difference is that I run it under Linux and not with the NI drivers. I
could duplicate the commands you're using and if the instrument doesn't
reset, then maybe it's the NI driver.

Tell me what commands you're using and I'll try it out.

[BeckyB]

Hello AllanH -

Have you tried using driver version 2.1? 

Please let me know if this corrects the problem. Have a great day!

Becky B.
Applications Engineer
National Instruments

[AllanH]

I have not yet tried driver version 2.1. The note here:

http://www.ni.com/support/gpib/versions.htm#note2

Seems to suggest to me that I should not use version 2.1 with my equipment, but I confess that the note is not entirely clear to me. It is safe to try using version 2.1 with a PCI-GPIB controller card on Window 2000? What is the difference between the two versions?

Thanks for your help,

Allan

[AllanH]

Thanks very much for your offer to help. The symptoms of my problem do not appear to have much to do with the commands being sent, however. Upon successful connection to the device, we execute:

RESET
TEST
LOCK 1

We then DMODE each of the cards on the SCUs. After that, the majority of all communication is simply calls to DREAD for each card. Depending on how fast we poll the SCU, the device eventually resets itself and we lose communication until it comes back, at which point we reinitialize it again and continue to poll it until it fails again. Even polling at a very slow rate eventually causes the reset. I suspect that the problem is not with the devices themselves, given that all three SCUs seem to reset themselves simultaneously.

Thanks a
gain for your offer to help,

Allan

[Methis Elddir]

On Wed, 03 Mar 2004 12:18:38 -0600, AllanH wrote:

> Thanks very much for your offer to help. The symptoms of my problem do
> not appear to have much to do with the commands being sent, however.
> Upon successful connection to the device, we execute:
>
> RESET
> TEST
> LOCK 1
>
> We then DMODE each of the cards on the SCUs. After that, the majority
> of all communication is simply calls to DREAD for each card. Depending
> on how fast we poll the SCU, the device eventually resets itself and we
> lose communication until it comes back, at which point we reinitialize
> it again and continue to poll it until it fails again. Even polling at a
> very slow rate eventually causes the reset. I suspect that the problem
> is not with the devices t
hemselves, given that all three SCUs seem to
> reset themselves simultaneously.
>
> Thanks again for your offer to help,
>
> Allan

Hi,

The only modules I have are the 44470A Relay Multiplexers so I don't know
if it's a fair comparison. I couldn't run the DMODE or DREAD commands but
I did run RESET, TEST, and LOCK 1. Then I let it perform a serial poll
every 1 ms. I let it run and then walked away. It performed over 30,000
serial polls without a reset before I stopped it.

I could try some more tests, the only problem is that I don't know the
command set for the instrument. Someone gave this box to me so I could
test out the Linux-GPIB driver on LabVIEW.

Could you try a test similar to what I just did? Probably a silly test
but I'm curious if it resets when you just when serial poll the
instrument, without prior interaction with the modules.

[BeckyB]

The driver version 2.1 offers more advanced features such as multithreaded/multiprocess behavior and locking functionality. More information on these and other enhancements is located here.

Driver version 2.1 is usually suggested only if you are using multiple GPIB devices. However, I'd recommend installing it to see if it fixes your problem.

Also, please check and make sure you have the current instrument driver for the HP3488A SCUs and the latest version of VISA (found here).

Becky B.
Applications Engineer
National Instruments

[AllanH]

I'll see if I can set up a test like you describe. Unfortunately, this hardware and software is part of a deployed system so time to test out theories is hard to come by.

Thanks again,
Allan

[AllanH]

I will try version 2.1 and let you know if it helps. As far as an instrument driver and VISA, I'm not actually sure what these are for, possibly LabView? If so, I should have clarified that I am talking to the SCU using low-level gpib calls via C++; that is to say custom software.

[BeckyB]

Yes, the instrument driver and VISA are used in LabVIEW. Sorry for the misunderstanding. Good luck!

Becky B.
Applications Engineer
National Instruments