LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Why slow buffer reading of hp53181a?

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

0 Kudos
Message 1 of 11
(3,377 Views)

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?


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 11
(3,350 Views)

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.


"Should be" isn't "Is" -Jay
Message 3 of 11
(3,341 Views)

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

--
Geoff Field, BE, CLAD, MIEAust
Professional geek, amateur stage-levelling gauge
0 Kudos
Message 4 of 11
(3,273 Views)

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

--
Geoff Field, BE, CLAD, MIEAust
Professional geek, amateur stage-levelling gauge
0 Kudos
Message 5 of 11
(3,256 Views)

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.

--
Geoff Field, BE, CLAD, MIEAust
Professional geek, amateur stage-levelling gauge
0 Kudos
Message 6 of 11
(3,250 Views)

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

 

 

0 Kudos
Message 7 of 11
(3,234 Views)

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

 

0 Kudos
Message 8 of 11
(3,231 Views)

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

--
Geoff Field, BE, CLAD, MIEAust
Professional geek, amateur stage-levelling gauge
0 Kudos
Message 9 of 11
(3,219 Views)

@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.

0 Kudos
Message 10 of 11
(3,211 Views)