Why slow buffer reading of hp53181a?

[zyx8783787]

Hi everyone,

I am trying to program our hp53181a frequency counter. I find very slow buffer reading from the counter. What I do in my LabVIEW program is as follows:

1. Use 'VISA write' to execute "MEAS:FREQ? 6 MHz, 0.001Hz, (@1);" for 5 times; 'tickcount' tells that the time for the counter to read frequency for 5 times is 26ms;

2. Then, use 'VISA read' to read the buffer of the counter; 'tickcount' tells the time for reading buffer is ~7s. 

This slow buffer reading is not good enough for our experiments. 

Does anyone also program this counter? Also find slow buffer reading? Can do me a favor and offer some help? 

Thanks

[crossrulz]

First of all, you probably shouldn't be sending 5 querries in a row without doing a read.  That might be confusing the counter.  Write the querry command and then do a read of the data.

What bus are you using?  Are you getting timeout errors?  Are you using termination characters?

[JÞB]

Query the actual resolution of that device.

I suspect that you are not getting 0.001Hz resolution.  It should be coerced to the min resolution available for the range.  If you really were trying to get mHz resolution the measurement would take significantly longer.

[GeoffF]

Hi there,

We're using this counter in a production environment and are (apparently) randomly seeing a similar issue.  The code used to do a CONFIGURE, then a MEASURE, then a READ in a continuous cycle.  At the same time, we read a HP441x power meter.  Our production staff were seeing this error quite frequently.

I've since increased the timeout to 5 seconds, dropped the separate (redundant) READ, and modified the code to do the CONFIGURE at startup and every 10,000 read cycles (configurable).  I also linked the error in/out lines so that the two meters don't try to access the GPIB connection simultaneously.

Even with these modifications, we're still getting occasions where there is no response and this error message pops up.  Given that it's a production environment, it would be ideal if these pauses didn't happen at all.  I'm seriously considering just masking the problem by catching and clearing that specific error.  I'm not sure about the recovery if I do, though.

Oh yes, I've checked the strings used in the HP/Agilent-provided driver and there are, in fact, newlines in there (as in the message here: http://forums.ni.com/t5/Instrument-Control-GPIB-Serial/Error-Hex-0xBFFF0015-timeout-problem-to-read/...

Geoff

[GeoffF]

Further information:

Actually, the string is selected from a multi-line string and the newline does NOT come through.  I wonder if this could be the source of the error?  It' susing the standard VISA Write function underneath.

Our original code was written in LV6 or 7.  The modified code uses LV2012 (specifically 12.0f3, 32-bit).  I don't think it's LV.  I suspect the instrument itself may be randomly freezing.  It could, alternatively, be the VISA driver, but we're not seeing the timeout from the power meter.

At present, our production workers simply acknowledge the message and re-start the program.  I'm in two minds about whether to:

 (a) Increase the timeout to, say, 10 seconds; 

 (b) Simply ignore the timout error;

 (c) Ignore the first error, but issue an instrument reset on the second consecutive timeout;

 (d) Ignore the first error, but bomb out of the program on the second consecutive timeout; OR

 (e) Just leave things as they are.  (This is the easiest option, given the amount of process associated with changing things in Production.)

Any thoughts would be welcome.

Geoff

[GeoffF]

The actual string sent is:

:MEAS:FREQ? 311MHz, 1Hz, (@2);

I've just read the NI white paper on the termination topic here:

http://www.ni.com/white-paper/4256/en/

It says "For VISA resource types that correspond to a complete 488.2 protocol (GPIB Instr, VXI/GPIB-VXI Instr, USB Instr, and TCPIP Instr), you generally do not need to use termination characters, because the protocol implementation also has a native mechanism to specify the end of a message. You need to tell VISA how messages are terminated only when using other VISA resource types (Serial Instr, USB Raw, and TCPIP Socket)."

So I guess I won't mess around with this, given that we're using GPIB.

[zyx8783787]

Hi Geoff, 

Thanks so much for your help. I had multiple contacts with the company and eventually figured out the problem: basically, commands using  ':MEAS:FREQ?' or 'CONFIGURE' can do a good job in single reading, but too much time-consuming for continuous reading. A solution to fast continuous reading is to use what is called 'running mode' (pls also refer to the 'to optimize throughput' example in the programming guide of this counter). Detailed solution is as follows (notes go after '//'):

1. Initialize the counter with 'VISA write':

*RST;

*CLS;
*SRE 0;
*ESE 0;
:STAT:PRES;
:EVEN1:LEV:AUTO OFF;LEV:REL 50;HYST:REL 100;SLOP POS;
:INP1:IMP 50;COUP AC;ATT 1;FILT ON;
:ROSC:SOUR INT;                                     //use internal oscillator
:ROSC:EXT:CHEC OFF;
*DDT #15FETC?;                                     //define trigger mode
:DIAG:CAL:INT:AUTO OFF;
:DISP:ENABLE OFF;
:HCOPY:CONT OFF;
:CALC:MATH:STATE OFF;
CALC2:LIM:STATE OFF;
:CALC3:AVER:STATE OFF;
FREQ:ARM:SOUR IMM;
:FREQ:ARM:STOP:SOUR TIM;
:FREQ:ARM:STOP:TIM 0.07S;                          //gating time=0.07s; the longer gating time is, the better frequency precision will be, but the longer measuring time will be (that is, time resolution becomes worse); 
:FREQ:EXP 6MHz;
:INIT:CONT ON;                      //use continuous mode or 'running' mode

2. Use the following in For-loop for multiple measurements using 'VISA write':

:FETC:FREQ? 

Then, use 'VISA read' right after the above command to read buffer

In my measurement, 0.07s gating time gives a precision better than 0.01Hz, and ~13 readings in 1 second. 

Regards,

Yuanxia

[zyx8783787]

The website messed up my message...Pls refer to the picture

[GeoffF]

Thanks for that Yuanxia,

I'm not concerned about getting high speeds, just reliable readings and a minimum of operator input requirement.  If I have to rewrite the driver to do so, so be it.

Geoff

[RavensFan]

---

@zyx8783787 wrote:

The website messed up my message...Please refer to the picture

---

Go to your Profile and My Settings.  Go to the Preferences Tab then Display.   For Emoticons, choose None rather than Use Default (Smiley) or any of the other ones.

That will prevent certain key combinations such as 😛 (colon P) or 😄 (colon D) from showing up as emoticons.  You had typed colon-S, so that looks like the Smiley Frustrated icon for anyone who didn't fix that setting within their profile.