Experimental Physics and
Industrial Control System

Don't you just hate those historical reasons?

>> Otherwise, why bother asking for PP?
>
>If you don't ask for PP then (assuming the record has SCAN=Passive) it
>would never process so the I/O operation would never get performed at all.

There is exactly one place in my database (quite a big one, about 6,500 records) where I wanted to update the value of an aiRecord from hardware AFTER I read out its old value.  All the other places, I wanted the return value to be up to date and it took some fiddling around to make things work.  As I think about it now, I am fairly sure that the only places I used PP INLINKs in the final IOC was to update the values of calcRecords, which are always synchronous and should be OK. 

In that one place I used a second aiRecord that read the value of the first record using an NPP INLINK and then FLNK'ed to the first record to make it update.  I had to it it this way because half the time I was running the database in simulation mode. Note that in simulation mode the value of the input record is updated synchronously, so it acts just like an asynchronous update of the hardware input, i.e. a PP INLINK will return the updated value in simulation mode, not the stale value.  While you are updating the documentation, it would be worth mentioning this inconsistency between hardware and simulation modes.

I am left with the feeling that the barn door is being closed after the horse has escaped.  Oh, well, at least I now know why that part of the IOC was hard to get right.

Cheers,
Russell O. Redman

-----Original Message-----
From: Andrew Johnson [mailto:[email protected]]
Sent: Mon 2006-02-06 15:13
To: Redman, Russell
Cc: [email protected]
Subject: Re: ASYN/devGPIB/GPIBCVTIO  problem

Redman, Russell wrote:
>
> 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.

The slightly strange behaviour probably stems from the addition of
asynchronous processing to record support somewhat later than the design
of the link API.  I'm guessing there as I wasn't involved when this was
written and Marty is no longer 2 doors down from my office, but in any
case I don't see an easy solution to achieving the behaviour that we
would all like - it would require major surgery on the database
processing code and all of the existing record types.

Reading a value through a link is an inherently synchronous operation in
the current API - you call dbGetLink() and expect the result to be there
as soon as the call returns.  If the link you're reading has its PP flag
set, dbGetLink() calls the record's process routine first and then grabs
the field value after it has returned.

Asynchronous record processing is by definition *not* a synchronous
operation - you call the record's process() routine, and it will return
almost immediately having started the I/O operation going.  There is no
indication to the caller that it hasn't finished, although the caller
could find out if it really wanted to by looking at the record's PACT
field.  The I/O operation will finish at some point later (we hope!) and
the associated device support will arrange for the record's process()
routine to be called, after which the new engineering value is available
to be read.

Reconciling the synchronous dbGetLink() call API with the asynchronous
record processing behaviour would require that dbGetLink() not return
until after the I/O operation has completed, which ties up the task that
is doing the dbGetLink() operation - it can't return until it knows the
value is available.  We don't know how long that will take though, it
may be half an hour for some devices (extreme, but legal).  Since it's
obviously not acceptable to suspend any of the existing scan tasks for
that period of time waiting for one device to finish, we have to accept
that the current design doesn't allow us to implement the behaviour we'd
like for PP links to asynchronous records.  [Ben, if you think you have
a working solution I'd love to see it.]

We can't change the record support asynchronous behaviour, so the only
answer is to redesign the dbGetLink() API and make it asynchronous.
That means using a new dbGetLinkCallback() call instead of dbGetLink().
  It also means that every routine that calls dbGetLink() would have to
split into (at least) two routines, since everything which currently
follows the dbGetLink() would have to be performed in a callback
routine.  There are 49 such calls in src/rec, 7 more in src/db, and an
unknown number in record types that are not shipped with base.

In the long term I'm sure we're going to want to resolve this issue, but
I don't think it's particularly high on the priority list and there are
other changes that we need to make to links which should be included in
any change of this magnitude.

> Otherwise, why bother asking for PP?

If you don't ask for PP then (assuming the record has SCAN=Passive) it
would never process so the I/O operation would never get performed at all.

- Andrew
--
* * Matt Santos / / For a Brighter America * *

References:

ASYN/devGPIB/GPIBCVTIO problem John Dobbins

Re: ASYN/devGPIB/GPIBCVTIO problem Tim Mooney

Re: ASYN/devGPIB/GPIBCVTIO problem Benjamin Franksen

RE: ASYN/devGPIB/GPIBCVTIO problem Redman, Russell

Re: ASYN/devGPIB/GPIBCVTIO problem Andrew Johnson

Navigate by Date:

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

Next: ChannelArchiver build error D. Peter Siddons

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 Andrew Johnson

Next: ASYN/devGPIB/GPIBCVTIO problem John Dobbins

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