There is another way to read a value as fast as possible, see http://www.aps.anl.gov/epics/tech-talk/2012/msg02097.php .
Yong
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Dirk Zimoch
Sent: Monday, January 07, 2013 8:33 AM
To: [email protected]
Subject: Re: streamDevice: how to read a value as fast as possible?
On 21.12.2012 22:21, Martin Konrad wrote:
> Hi,
> I want to read out an LXI compatible power meter (Agilent N1912A) with
> StreamDevice. Depending on its configuration (averaging etc.) this
> device might need very different time to acquire a value. Nevertheless
> I always want the device to acquire data continuously. I also want to
> get the data with a time stamp that is close to the time the data
> acquisition was finished.
>
> Unfortunately I did not find a way to configure the device to send new
> (unsolicited) data as soon as acquisition is finished. But the device
> supports two read-out modes:
>
> 1. A synchronous "READ?" command that in some cases blocks for more
> than a minute. Running this command continuously is obviously not
> exactly a nice solution. But anyhow: Is there a way to issue the next "READ?"
> command right after the previous one finished?
> 2. A free-running mode (device automatically starts the next
> acquisition as soon as the first one is finished). In this mode the
> interface is never blocked and data can always be read out with the
> "FETCH?" command which immediately returns the last reading. Using
> this command with
> SCAN=".1 second" leads to a lot of unneeded record processing (as well
> as CA traffic to clients that monitor this PV and also archiving load).
> Is it possible to avoid processing of my ai record if the VAL field
> did not change? It seems to me that this is a limitation caused by the
> asynchronous behavior of Asyn/StreamDevice...
>
> Any ideas?
>
> Martin
>
1. Let the FLNK of your record point to its own PROC field and make it a CA link. Also set PINI YES to start the loop. Use a long ReplyTimeout, e.g. 600000 (= 10 minutes)
If you want to be able to start and stop the loop, let the SDIS link point to a bo record which acts as a switch. (But pending requests are not interrupted.) In order to restart the loop, let the FLNK of the bo record point to your original record's PROC field and make it a CA link, too.
2. If the device supports SRQ, this could in theory be used to trigger the fetch record. But unfortunately gpib SRQ handling is asyn is broken (or most properly never worked).
Dirk
- References:
- Re: streamDevice: how to read a value as fast as possible? Dirk Zimoch
- Navigate by Date:
- Prev:
APS Web Server upgrade in ~5 hours Andrew Johnson
- Next:
rsrv and cas Jack Smith
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
<2013>
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: streamDevice: how to read a value as fast as possible? Dirk Zimoch
- Next:
RE: streamDevice: how to read a value as fast as possible? Mark Rivers
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
<2013>
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|