Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Fri, 21 Dec 2012 21:40:18 +0000

Martin,

> 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).

It does lead to record processing.  But it does not lead to CA traffic or archiving load if the value has not changed, because the ai record does not post monitors for value changes if the value change since last processing is less than MDEL, and it does not send out monitors for archivers if the value change is less than ADEL:

        monitor_mask = recGblResetAlarms(prec);
        /* check for value change */
        delta = prec->mlst - prec->val;
        if(delta<0.0) delta = -delta;
        if (delta > prec->mdel) {
                /* post events for value change */
                monitor_mask |= DBE_VALUE;
                /* update last value monitored */
                prec->mlst = prec->val;
        }

        /* check for archive change */
        delta = prec->alst - prec->val;
        if(delta<0.0) delta = -delta;
        if (delta > prec->adel) {
                /* post events on value field for archive change */
                monitor_mask |= DBE_LOG;
                /* update last archive value monitored */
                prec->alst = prec->val;
        }

If you want to avoid the overhead of record processing, then you can write a simple asyn port driver that polls the device with FETCH? and only does callbacks to device support if the value has changed.  The ai record would have SCAN=I/O Intr in this case.  If you derive your code from asynPortDriver doing the callbacks to device support is 1 line of code, including the check to see if the value has changed, since that is automatic.  The entire driver should be less than 200 lines of code.

Mark

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Martin Konrad
Sent: Friday, December 21, 2012 3:22 PM
To: [email protected]
Subject: streamDevice: how to read a value as fast as possible?

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

-- 
Dipl. Phys. Martin Konrad
Technische Universität Darmstadt
Institut für Kernphysik
Schlossgartenstr. 9
64289 Darmstadt
Tel.: +49-6151-16-5121
Fax: +49-6151-16-4321

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System