Re: breaktable checks in dbLexRoutines.c in 3.14.9

[Andrew Johnson <anj@aps.anl.gov>]

Hi Steve,

Steven Hartman wrote:
> I have come across another problem with changes made between 3.14.8.2 and
> 3.14.9. In base/src/dbStatic/dbLexRoutines.c, sanity checks were added to
> breakpoint tables (as are used in ai and ao LINR fields). These checks
> appear to have been added in response to a message to tech-talk from May,
> 2006 (see thread starting with:
> http://www.aps.anl.gov/epics/tech-talk/2006/msg00585.php ). However, one
> of these checks is too strict and does not accept a number of properly
> functioning breakpoint tables which work under previous releases.

Your research into the history of those changes is correct, however I 
beg to differ with your assertion that the previous behavior was correct 
and would work in all circumstances.

> A breakpoint table by definition needs a monotonic 'x' parameter
> (restricted usually to only increasing values), but there should not be
> any restriction for slope or monotonicity for the 'y' parameter. This
> check rejects a breakpoint table if either x or y is non-monotonic. This
> greatly reduces the usefulness of the breakpoint table.

I accept that a one-directional breakpoint table only needs be monotonic 
in the X direction, but unfortunately the EPICS breakpoint tables are 
bi-directional.  The same table can be used for both ai and ao records, 
and there is no indication when you load one whether X will map to the 
engineering unit values or the raw values.  Even worse than that, the ao 
record type uses its table both ways - in init_record() it calls 
cvtRawToEngBpt() to set the VAL field from the initial device read-back, 
and then in convert() it calls cvtEngToRawBpt() to generate the new raw 
output values towards the end of record processing.

> I suggest either dropping this check entirely and documenting that
> it is the application developer's responsibility to ensure proper
> monotonicity, or changing the abort to a warning (which would likely add
> confusion during the build process).

Unfortunately with the ao record using its table in both directions I 
don't feel completely happy with the idea of just removing the check for 
everyone.

> We make extensive use of breakpoint tables here at the DFELL (mapping
> effective field to current in nonlinear magnets which is monotonic, and
> mapping compensation trim magnet fields to main magnet fields which is
> extremely non-monotonic).

Have you looked at the possible effects on your systems if an ao record 
reads its initial raw value from the hardware and uses the wrong part of 
a table to calculate its initial engineering unit value?  If you don't 
use that bumpless reboot feature of the ao record it won't be a problem 
for you, but some sites do rely on that feature.

I would accept a compromise solution which is to allow the check to be 
disabled, although you'd have to load your breakpoint tables from a 
different DBD file than the main IOC one with the approach I have in 
mind (the dbExpand program will still reject a non-monotonic breaktable 
definition, but the IOC's dbLoadDatabase command could be made to accept 
them without complaint by adding one line to the st.cmd file).

I'd be interested to hear comments from others about this issue, 
including about my proposed solution.

- Andrew
--
When a distinguished but elderly scientist states that something is
possible, he is almost certainly right.  When he states that something
is impossible, he is very probably wrong.  -- Arthur C. Clarke