Re: breaktable checks in dbLexRoutines.c in 3.14.9

[Steven Hartman <hartman@fel.duke.edu>]

On Fri, 10 Aug 2007, Andrew Johnson wrote:

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

In the case of an ao record which uses the same table with both
cvtRawToEngBpt() and cvtEngToRawBpt(), both the raw and engineering values
must be monotonic.  But in the case of an ao record which only uses
cvtEngToRawBpt(), or an ai record which can only use cvtRawToEngBpt(), the
check is too strict. I am not, obviously, requesting that the values of
either the raw or the engineering units must be non-monotonic, only that
one of them may be.

The problem is, as you said, that there is no way to know at load time
which way the table will be used. But rejecting a table which is safe to
use with an ai record using cvtRawToEngBpt() because it is not safe to use
with cvtEngToRawBpt() is too restrictive.


> 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 am only using cvtRawToEngBpt(), similar to an ai record. The raw values
are always monotonic and increasing. The engineering values may be any
arbitrary function. The tables are only used in one direction.

-- 
Steve Hartman
hartman@fel.duke.edu || 919-660-2650
Duke Free Electron Laser Laboratory