> 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).
I have heard about a couple of problems with the asyn VXI-11 support. If possible I would like to get these fixed before the next release of asyn, which is otherwise ready to go.
I don't have any experience with VXI-11, and don't own any VXI-11 devices myself. But I think I could borrow one from elsewhere at the APS.
Those who have had VXI-11 problems with aysn:
- Can you please describe exactly the symptoms? I seem to recall that the SRQ problem manifested itself as the IOC crashing if an SRQ was asserted when the IOC boots. Is this true? Do SRQs work otherwise?
- Can you give me a specific device and configuration that will reproduce the problem? Hopefully a relatively common device like a digital scope that we may have here at the APS?
Thanks,
Mark
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Dirk Zimoch
Sent: Monday, January 07, 2013 7: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:
RE: Problem with mca R7.2 and Rontec XFlash Mark Rivers
- Next:
How to set property 'items' of ComboBox from a javascript in CSS BOY Xinyu.Wu
- 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? Hu, Yong
- 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
|