Experimental Physics and
Industrial Control System

"Mark Rivers" <[email protected]> · Sun, 5 Feb 2006 10:49:56 -0600

John,

The behavior you are observing is documented in the Application
Developer's Guide:

5.9.2 Obtain Old Data
A dbGetLink to a passive asynchronous record can get old data.
If A is a passive asynchronous record then the dbGetLink request forces
dbProcess to be called for A. dbProcess
starts the processing and returns. dbGetLink then reads the desired
value which is still old because processing will only
be completed at a later time.

Mark

> -----Original Message-----
> From: John Dobbins [mailto:[email protected]] 
> Sent: Sunday, February 05, 2006 10:09 AM
> To: Tim Mooney
> Cc: [email protected]
> Subject: Re: ASYN/devGPIB/GPIBCVTIO problem
> 
> Tim,
> 
> Thanks for the clarification. The Record Reference Manual 
> (Chapter 1) reads:
> 
> "For input links such as INP or DOL (desired output 
> location), if they specify 
> PP, they will cause the record whose address they contain to 
> process when the 
> records containing them are processed ... This means that the 
> value will be 
> retrieved from the specified record only after the record has 
> processed its data."
> 
> Which I had understood to mean that the input link would in 
> fact fetch a fresh 
> value.
> 
> John
> 
> Tim Mooney wrote:
> > John, regarding...
> > 
> > John Dobbins wrote:
> > 
> >> Dear All,
> >>
> >> I am confused about what is happening with an Analog In record 
> >> connected to an ASYN device. In particular this is a 
> devGPIB device 
> >> with a command of type GPIBCVTIO.
> >>
> >> I have created the custom convert routine for this devGPIB 
> GPIBCVTIO 
> >> command and it appears to work, i.e. I have connected it 
> to an Analog 
> >> In record and if from the EPICS command line I force the record to 
> >> process (dbpf aiRecord.PROC 1) and then examine the record's value 
> >> (dbpr aiRecord) it has correctly retrieved the value from hardware.
> >>
> >> However, I next did the following:
> >>
> >> I added a dfanout record and an Analog Out record. All 
> three records 
> >> are passive. I set the DOL of the dfanout record to be the 
> >> "aiRecord.VAL PP" and OUTA of the dfanout record to be the 
> >> "aoRecord.VAL PP".
> >>
> >>       aiRecord -> dfanoutRecord -> aoRecord
> >>
> >> I see this behavior when I make dfanoutRecord process:
> >>
> >> 1) aiRecord processes
> >> 3) ao record processes writing the stale value, i.e. the value the 
> >> aiRecord had before it processed
> >>
> >> Note, from ASYN diagnostic output I see #1 happen and then 
> #3 happen.
> >>
> >> I infer that in between these the following happened
> >>
> >> 2) dfanoutRecord retrieved stale data from aiRecord and 
> passed it to 
> >> aoRecord
> >>
> >> So the question is why is the dfanout record retrieving the stale 
> >> value? It seems it must be that the value is retrieved before the 
> >> aiRecord is actually done processing.
> >>
> >> The last lines of my convert routine are:
> >>
> >>        precord->val = floatData;
> >>        precord->udf = 0;
> >>
> >>       return 0;
> >>   }
> >>
> >> After which the code in devGPIB is responsible for setting 
> PACT = 0.
> >>
> >> Have I gone wrong somewhere? Any advice appreciated.
> >>
> >> info: EPICS 3.14.7, ASYN 4.2.1, Linux IOC
> > 
> > 
> > That's the way it's supposed to work.  The only thing that waits for
> > asynchronous processing is the forward link of the record 
> whose device
> > support is asynchronous.  This is not peculiar to ASYN; 
> it's a general
> > feature of asynchronous processing.  A PP input link starts 
> processing
> > that will eventually return the new value, but just takes 
> whatever value
> > is there.  Otherwise it would hold up all the other records 
> being processed
> > by the same task.
> > 
> > John Dobbins wrote:
> >  > A follow up note:
> >  >
> >  > I changed dfanoutRecord DOL to be "aiRecord.VAL NPP" and 
> then used a seq
> >  > record to first process aiRecord and then after a delay process
> >  > dfanoutRecord.
> >  >
> >  > This fixes the bad behavior which is consistent with the 
> theory that
> >  > dfanout was grabbing aiRecord.VAL too soon.
> >  >
> >  > Also note that if I replace dfanout with an ao, DTYP = 
> "Soft Channel" I
> >  > see the same behavior, so this problem is not specific 
> to dfanout.
> > 
> > You might also have the forward link of the AI record 
> process the dFanout
> > record.  Then you would not have to guess how long a delay to use.
> > 
> 
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System