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
<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: RAWF, RAWL Andrew Johnson
- Next:
Re: RAWF, RAWL Marty Kraimer
- 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
|