EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  <20012002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  <20012002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: RAWF, RAWL
From: Benjamin Franksen <[email protected]>
To: EPICS tech-talk <[email protected]>
Date: Fri, 17 Aug 2001 16:46:08 +0200
Andrew Johnson wrote:
> 
> > What should happen if device support doesn't provide a special_linconv()
> > routine?  Currently EOFF is set from EGUL, but ESLO keeps its old value
> > (1.0 by default).  It's easy to allow manual setting of both in this case
> > too, although I'm not sure whether this is the right thing to do when
> > LINR=SLOPE is available to permit that.  I note that the Raw Soft
> > supports both provide a special_linconv() routine which does nothing so
> > unless these are also changed they will retain the current behaviour
> > anyhow.

When I thought about that, I discovered a problem that is even worse:if
linear conversion is supported by device support, dset->init_record must
do (and usually does) what is at run-time done by dset->special_linconv.
Otherwise ESLO and EOFF are not initialized correctly. Unfortunately we
cannot rely on device supports doing so only if LINR == LINEAR, because
up to now these values would be ignored in case LINR != LINEAR so it was
correct to overwrite them in any case.

The only solution I can think of: in case LINR == SLOPE, record support
has to save the values of ESLO and EOFF and reinstall them after
dset->init_record has been called. Yes, it's ugly.

With the wisdom of hindsight it was of course a bad idea not to keep
device support operations orthogonal. The initializing call to
dset->special_linconv should be done from the record support rather than
device support.

However, the correct approach is:

If LINR == SLOPE device support should be ignored and EOFF should not be
set by record support. Make sure that in case dset->init_record changes
ESLO or EOFF this has no effect by saving them before and restoring them
after the call to dset->init_record.

If LINR == LINEAR, set EOFF = EGUL and proceed with calling
dset->special_linconv if it exists. If not, issue a warning that that
device support doesn't support linear conversion. Setting EOFF = EGUL
must still be done in this case, because there are definitely
applications that rely on this behavior (i.e. that EGUL is always added
to the raw value if LINR==LINEAR) which we don't want to break.

In addition, inside the record support's init_record, call
dset->special_linconv after calling dset->init_record, but only if
LINR=LINEAR. So future device supports need not set ESLO or EOFF inside
init_record.

> when Marty pointed out that by introducing a new state into
> menuConvert.dbd we would break any existing applications that add their
> own breakpoint tables (because they provide their own copy of
> menuConvert.dbd and are only allowed to add items to the end of the menu
> defined in base), and possibly the AllenBradley 1771IXE device support
> which apparently makes assumptions about the LINR field.  Aarrrgghh!!!
> These changes can be made, but probably not in a minor release (breaking
> backwards compatibility is generally verboten for minor releases).  Thus
> Marty is willing to accept the above in 3.14, but not in a 3.13.x release.
> 
> Life is never as simple as we'd like it to be.

Yes, *sigh*. I fully agree to schedule this for 3.14 rather than in
3.13. I anticipated the problem with the replacements of
menuConvert.dbd, therefore the "almost" in my claim of backward
compatibility - but not the problem of device or driver supports relying
on the numerical values of the enums in menuConvert. I thought it to be
acceptable to change the dbd files since there is at most one for each
IOC and the change amounts to adding one line in a well defined
position. It can be done automatically by a one-line perl or sed script.

This copy-and-paste style of extension of a base feature was a kludge to
start with and never fitted well into the otherwise (apart from the link
types) nice and clean extension mechanisms in EPICS. No wonder adding a
state to the definition in base causes problems. This was one major
reason I wanted to get rid of it.

The problem with device and driver supports is serious. I have no better
idea how to proceed here than to check each and every module for
occurrences of '->linr' and manually remove references to assumed
numerical values. This is why making such assumptions is such a bad
programming style and should be most strongly discouraged. I looked at
the allenBradley support in the APS repository. It looks as if only the
old version (under subdir 'oldSrc') makes use of linr field in this way
("if(prec->linr>=2 ..."). This must be changed or it won't work with
3.14. In the other subdirs, a single assignment to linr still exists
(linr = 0), but that is not needed (because 2 is returned from read_ai)
and so can be eliminated. We still have to check the other modules :(

Ben


Replies:
Re: RAWF, RAWL Marty Kraimer
Re: RAWF, RAWL Andrew Johnson
References:
RE: RAWF, RAWL Redman, Russell O.
Re: RAWF, RAWL Marty Kraimer
Re: RAWF, RAWL Benjamin Franksen
Re: RAWF, RAWL Marty Kraimer
Re: RAWF, RAWL Andrew Johnson
Re: RAWF, RAWL Benjamin Franksen
Re: RAWF, RAWL Andrew Johnson
Re: RAWF, RAWL Benjamin Franksen
Re: RAWF, RAWL Andrew Johnson

Navigate by Date:
Prev: Re: An additional remark on C++ Chip Watson
Next: Re: An additional remark on C++ Benjamin Franksen
Index: 1994  1995  1996  1997  1998  1999  2000  <20012002  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: RAWF, RAWL Andrew Johnson
Next: Re: RAWF, RAWL Marty Kraimer
Index: 1994  1995  1996  1997  1998  1999  2000  <20012002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·