> 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?
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Dirk Zimoch
Sent: Monday, January 07, 2013 7:33 AM
Subject: Re: streamDevice: how to read a value as fast as possible?
On 21.12.2012 22:21, Martin Konrad wrote:
> 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?
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,
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).
- Re: streamDevice: how to read a value as fast as possible? Dirk Zimoch
- Navigate by Date:
RE: Problem with mca R7.2 and Rontec XFlash Mark Rivers
- Navigate by Thread:
RE: streamDevice: how to read a value as fast as possible? Hu, Yong
epics input and output via records James F Ross