Experimental Physics and
Industrial Control System

I, too, read the Record Reference Manual and had no idea that PP input links to asyncronous records would always return stale data.  This may account in part for the long, confusing struggle I had to ensure that my SNL state machines would only make critical decisions AFTER the input records had read back up-to-date values.

I am still not clear on the logic of the original behaviour.  If I want to read a value from an asynchronous input record, and I do not care whether it is up-to-date, I can use an NPP INLINK to fetch the current value.  If I specifically ask for a PP INLINK, that surely indicates that I need a completely up-to-date value and that stale data is unacceptable.  Otherwise, why bother asking for PP?  If a PP INLINK does not ensure valid data, what does?

Cheers,
Russell O. Redman

-----Original Message-----
From: Benjamin Franksen [mailto:[email protected]]
Sent: Mon 2006-02-06 08:33
To: [email protected]
Subject: Re: ASYN/devGPIB/GPIBCVTIO  problem

On Sunday 05 February 2006 15:15, Tim Mooney wrote:
> John Dobbins wrote:
> >       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
>
> That's the way it's supposed to work.

I beg to differ. It may be well-documented (and historically
understandable), but it still is an annoying and frustrating
mis-feature, and definitely not how any sane person would expect it to
work.

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

Not if asynchonicity could be inherited via input or output links. Which
would mean (1) every record support must support asynchronous
processing and (2) we can pass a callback to dbPutLink resp. dbGetLink.
That's it, mostly.

V4 was supposed to fix this limitation (and many others). Maybe this one
would be a candidate for inclusion into some V3.16? I'll hapily
volunteer to hack the IOC core to support this...

Ben

Replies:

Re: ASYN/devGPIB/GPIBCVTIO problem Andrew Johnson

References:

ASYN/devGPIB/GPIBCVTIO problem John Dobbins

Re: ASYN/devGPIB/GPIBCVTIO problem Tim Mooney

Re: ASYN/devGPIB/GPIBCVTIO problem Benjamin Franksen

Navigate by Date:

Prev: Re: Ioc denial of service attacks Lawrence T. Hoff

Next: Re: Ioc denial of service attacks Maren Purves

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: ASYN/devGPIB/GPIBCVTIO problem Benjamin Franksen

Next: Re: ASYN/devGPIB/GPIBCVTIO problem Andrew Johnson

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