GPIB data transfer error with HP4194a Analyzer

[auth]

Good afternoon,

Recently my boss came to me and asked me to write a LabView program for the HP4194a Impedance Analyzer. I seem to have successfully completed that task using the instrument driver and example as a basis for it, but I have an intermittent data transfer error.

Basically, I'm running the HP analyzer over the GPIB using labview 8.5.1. It sets all of the parameters correctly, and does a magnitude/phase sweep, then retrieves registers A,B,X. When we retrieve A, B, or X, something seems to go wrong intermittently and we get a column of data that has the number of points in the first value of the array, and the rest of the column is zeros.  About half of the time it does this, it repeats the error, on a different data column several times. Below there's a few example data sets that I made up to illustrate it. The timing is left to right.
1:                                                           2:                                                          3:
Using just 4 demo points
Freq(X)   Mag(A)   Phs(B)                     Freq(X)   Mag(A)   Phs(B)                     Freq(X)   Mag(A)   Phs(B)
100          12354      401                         401          12354      401                        100           12354      -90
   -                -            0                              0                -            0                             -                0            -
   -               -             0                              0               -             0                              -               0            -
1000        234           0                               0            234           0                          1000            0           -110

If you look at example 3, you'll notice the column of Mag doesn't have the number of points in the first spot. I don't understand why, but the first value in the magnitude is always the correct value according to the machine. Also, I say intermittently because some days this problem simply doesn't appear. Some days it appears a lot. I originally thought it was GPIB read/write time, but I checked the manual for the analyzer and my time gives it more than enough time to transfer all of the data, and lengthening and shortening the time doesn't affect the error at all.

Also, I've been trying to force this error for the last few days, and I can't find a way to reproduce it on demand. I've done everything I can think of from removing the read delay to making the read delay 10 seconds, changing settings, reading multiple times, etc. The only thing that seemed to make the error appear more often was changing the integration time. A long (setting on the machine) integration time with an 840 ms read delay caused the error to appear more often.

Has anybody seen this error before, or does anyone have any suggestions for tracking it down?

Thank you,
-Matthew Dumas
matthew.dumas@authentec.com

[Song_M]

Hey Auth!
A couple of quick questions.  Did you try the original Instrument driver for HP4914a Analyzer?  If so, does that driver provide the same error?  Secondly, are you getting an error code?  Thirdly, could you provide a copy of NI spy?  I have listed the link regarding how to provide NI spy capture on bottom

http://digital.ni.com/public.nsf/allkb/8D890EC09B15C05A86256E6F007E3E86?OpenDocument

Thank you Auth!  Have a great day!

[auth]

I am using the driver for the HP4194a that is currently installable from the search utility.  I have no other interfaces with the machine.

There are NO errors provided at all. Occasionally I get instrument error 12, but that is "0 Not allowed in log sweep."

Finally, thank you for the link. When I follow the instructions on that website, I cannot get the error at all. Granted, I've only tried for about 35 minutes, but this appears to be a Heisenbug. IE: A bug that disappears when the debugger is present.  I tested that theory by turning off the NI Spy. Within 3 minutes of turning it off, I got the error.  I really hope I'm wrong about that. For the future testing, I'm going to leave NI Spy on in hopes that it isn't a heisenbug. If I can catch the bug with NI Spy I'll post again with the data. I have a fairly large test coming up soon, so I should be able to reproduce it.

Thanks for the help,
-M

[Song_M]

Hey Auth!
Keep me updated.  Thank you!

[auth]

Song_M,

I'm not really sure how to update you, other than with bad news for finding the bug.

I've set the program to autoloop (and stop on error), and it has been running since Wednesday morning. It hasn't once caught the error. However, when I turn of NI Spy, the error usually isn't far behind. I'd love to get to the bottom of this, is there another debugger I can use, or do we know exactly how NI Spy interacts with the VISA interface over the GPIB?

Since the testing isn't moving forward for a little while, I'm going to keep the program running on the off chance that it might throw the error, but I don't believe it will. If I have to, I don't mind running NI Spy for all of the testing, but I'd prefer to find this error.

Thanks for all of your help,
-M

[Brian_Beal]

This is a classic case of an original GPIB spec instrument being used with modern PC's.  First thing to try is to slow down the GPIB bus speed, but that usually doesn't help.  The only thing I've found that works on the 4194a is to add delays(about 30 ms) after each read and write.  I don't use the 4194a drivers, so I don't know what is involved in changing them, but I created my own GPIB read and write VI's that include the delay.  NI Spy slows down comms, so that is why it doesn't happen when it is running.

[Song_M]

Brian!
Thank you for your insight.  Great advice!

[auth]

Yes, Brian, thank you!

I modified the standard drivers distributed by NI to include the delay, and it has been running without error or NI Spy since you posted yesterday. I appreciate all of the help from both of you.  If the error turns up over the weekend I'll post, but as I said, it's been running since last night with no errors, so it looks to be pretty good.

Have a good day,
-M

[Yuriy Gritsenko]

I just wanted to let you all know that I had the same issue with a driver on which I was working and took Brian's advice and after a bit of testing, I can confidently say that the problem is fixed.  The delays do the job wonderfully.  Even a 10 ms delay seems to work fine.  Thanks!