Experimental Physics and
Industrial Control System

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.

Replies:

Re: breaktable checks in dbLexRoutines.c in 3.14.9 Andrew Johnson

References:

breaktable checks in dbLexRoutines.c in 3.14.9 Steven Hartman

Re: breaktable checks in dbLexRoutines.c in 3.14.9 Andrew Johnson

Re: breaktable checks in dbLexRoutines.c in 3.14.9 Steven Hartman

Navigate by Date:

Prev: Re: breaktable checks in dbLexRoutines.c in 3.14.9 Steven Hartman

Next: Re: breaktable checks in dbLexRoutines.c in 3.14.9 Andrew Johnson

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: breaktable checks in dbLexRoutines.c in 3.14.9 Steven Hartman

Next: Re: breaktable checks in dbLexRoutines.c in 3.14.9 Andrew Johnson

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