Experimental Physics and Industrial Control System
|
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
- Replies:
- RE: streamDevice: how to read a value as fast as possible? Hu, Yong
- RE: streamDevice: how to read a value as fast as possible? Mark Rivers
- Navigate by Date:
- Prev:
Re: time drift in camonitor timestamps Michael Davidsaver
- Next:
epics input and output via records James F Ross
- 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: time drift in camonitor timestamps Andrew Johnson
- Next:
RE: streamDevice: how to read a value as fast as possible? Hu, Yong
- 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
|
ANJ, 20 Apr 2015 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|