Power Measurement Take Too Long

[BryanL]

Hi All,

I am using Agilent 8163B with 2 slots:  81619A (2 heads) and 81618A (1 head) for power measurements.  I setup my measurement with Agilent's time sutup driver vi at 5 seconds average time.  However it took over 20 seconds total to complete the measurement of 3 channels using the Agilent's 816x Read PMW Value.vi (this VI calls a DLL hp816x_32).

My question is that can I get this measurement done close to 5s with a parallel read of 3 channels at the same time?  i.e., Is the DLL hp816x_32 reentrant?

I tried to have a parallel wiring of 816x Read PMW Value.vi to test this, but still get a measuement time of 21 second.  Does anyone has a suggestion to improve this?

Thanks,

Bryan

[F._Schubert · Accepted solution]

I'm not familiar with that specific hardware. But how long does it take if you only measure a single channel? If this also takes 20 s I guess that the vi is configuring the device each time it runs (this is a painful overhead). You can go down to the basic commands using READ and FETCH? for best speed on similar devices (I don't remember too much of the syntax). 

Felix 

[billko]

---

BryanL wrote:

Hi All,

I am using Agilent 8163B with 2 slots:  81619A (2 heads) and 81618A (1 head) for power measurements.  I setup my measurement with Agilent's time sutup driver vi at 5 seconds average time.  However it took over 20 seconds total to complete the measurement of 3 channels using the Agilent's 816x Read PMW Value.vi (this VI calls a DLL hp816x_32).

My question is that can I get this measurement done close to 5s with a parallel read of 3 channels at the same time?  i.e., Is the DLL hp816x_32 reentrant?

I tried to have a parallel wiring of 816x Read PMW Value.vi to test this, but still get a measuement time of 21 second.  Does anyone has a suggestion to improve this?

Thanks,

Bryan

---

Looking through theUser's guide at: http://cp.literature.agilent.com/litweb/pdf/08164-90B15.pdf on page 100, "How to Set Averaging Time," it states that:

---

If the measurement condition change (for example, a range change in
automatic ranging), Pold is reset and the averaging starts again. This is why
the display update seems faster in automatic ranging.

---

Maybe your measured power is hovering near a range limit?
 
Bill

[BryanL]

Felix and Bill,

Thank you so much for the great suggestions. I have been trying with the Fetch command instead of Read Value command as Felix suggested, which is also what Agilent was recommending to use for multiple channels.  I am still not getting it working yet.  I also tried with setting internal trigger to "immediate" instead of "contineous", with or without "start internal trigger" command, and was hopping to have 3 channels triggerred independently.  Next thing is to try Bill's suggestion of range setting..I will see if it helps. 

Meanwhile, I would appreciate any other comments or suggestions.

Thanks

Bryan

[billko]

---

BryanL wrote:

Felix and Bill,

Thank you so much for the great suggestions. I have been trying with the Fetch command instead of Read Value command as Felix suggested, which is also what Agilent was recommending to use for multiple channels.  I am still not getting it working yet.  I also tried with setting internal trigger to "immediate" instead of "contineous", with or without "start internal trigger" command, and was hopping to have 3 channels triggerred independently.  Next thing is to try Bill's suggestion of range setting..I will see if it helps. 

Meanwhile, I would appreciate any other comments or suggestions.

Thanks

Bryan

---

Bryan:

I really feel you are travelling down the right path.  I think you will find the correct combination of commands to make it work!  Keep it up!  You're doing exactly the kinds of stuff I would be doing, if that gives you a vote of confidence.  😉

Bill

[BryanL]

Thanks for the encouragement! Just needed it.

I believe it had been working with the Fetch command, I was having a silly logic mistake that never started my while loop earlier.  Now things are as expected, i.e., I am getting power updates read out every 5s when average time was set to 5 seconds.  Though my loop was running much faster, i.e., the DLL returns immediately (no 5s wait), only that the value is the same before the 5s is over. I am still using "contineous" trigger though.  I think I am still getting the 5s averaged data read out unless someone object to that. 

Regards,

Bryan

[johnsold]

Bryan,

I am not familiar with your instrument, but some other instruments will return the last available measurement if you repeat the Fetch command before the instrument has completed the next measurement. For example let the measurement after 5 seconds be 1.3 and the one five seconds later be 2.7.  If the Fetch command is sent every 1.5 seconds starting at t = 0, the readings would be something like this:

tr        1.5   3.0   4.5  6.0   7.5  9.0   10.5   12.0...

Meas.    ??    ??     ??  1.3   1.3  1.3     2.7     2.7...

Is this what you are seeing?

Lynn 

[billko]

I'm a good one for posting links, it seems:

http://cp.literature.agilent.com/litweb/pdf/08164-90B64.pdf

This is the programmer's guide.  Page 195 discusses using the fetch command.  It seems to be setting up for an averaged reading!  The code is in C but you can see what commands they are using and it is documented really well.  You should be able to follow along and see how they are accomplishing things.

I hope this helps!

[BryanL]

Lynn and Bill, thanks a lot for following up on my questions.  In my testing VI module I put "fetch" vi in a while loop after sending "initialize" and "average time" commands outside the loop.  When I set the "averaging time" to 5 seconds, I can see the power values from 3 channels are updated at about every 5 seconds. At the same time I monitored the loop index which updates at a far faster rate. This behavior must suggesting that the "fetch" vi was getting the same value within that 5 seconds when my loop was running repeatedly.  This value must be an average value as it didnt change within the 5second time window.  I guess my observation is indeed different from what Lynn posted. I did come across the programming guide yesterday as shown in Bill's link, but didnt look in detail, you know how we LabVIEW programmers got spoiled by the graphic code

After another look at the guide, it made more sense to my observations, i.e., Fetch command returns an average value right away and you can fetch all 3 channels. While the Read command triggers an measurement and exclude access to other channels after one read command was sent.  I also googled arount a little, and found the following text (not exactly for 8163B though) maybe also helpful to others in a similar situation.

Thanks again

Bryan

---------------------------------------------------------

The READ? command provides a sequential method to make measurements and retrieve the results. READ? will hang the GPIB bus until the measurement is completed, or until the timeout value has been exceeded. Associated SETup commands (for each measurement) are used with the READ? command to retrieve desired measurement results in a sequential manner.

Sending a READ? command is equivalent to an INITiate/FETCh cycle for a measurement. A READ? command executes an abort action on that measurement followed by an INITiate and a FETCH?.

READ? commands can be mixed with FETCH? queries in order to make combinations of sequential and overlapped operations. One measurement can be issued a READ? command (sequential), and the next measurement can be issued INITiate/FETCh? commands (overlapped), if necessary.

The advantage of using the READ? commands to obtain measurement results, as opposed to the INITiate/FETCh method is:

• It is simpler. Fewer commands are required to obtain measurement results.

Some disadvantages of using READ? over INITiate and FETCh are:

• The test set does not process any additional GPIB commands until the requested measurement results are available.
• The sequential nature of the READ? command does not allow the user to make concurrent measurements. Concurrent measurements require the overlapped commands INITiate, DONE? and FETCh? .

• The READ? command does not provide measurement results such as statistics that are available using the INITiate/FETCh method.
• The READ? commands have pre-defined measurement results. If additional results are needed from a measurement they may be obtained with a FETCh? query.

[billko]

Awesome - thanks for the feedback!