EPICS Home EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

Format page
for printing


Search Tech-talk
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  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 
<== Date ==> <== Thread ==>
Subject: Re: breaktable checks in dbLexRoutines.c in 3.14.9
From: Andrew Johnson <[email protected]>
To: Steven Hartman <[email protected]>
Cc: EPICS Tech Talk <[email protected]>
Date: Fri, 10 Aug 2007 14:46:50 -0500
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
Replies:
Re: breaktable checks in dbLexRoutines.c in 3.14.9 Steven Hartman
References:
breaktable checks in dbLexRoutines.c in 3.14.9 Steven Hartman
Navigate by Date:
Prev: breaktable checks in dbLexRoutines.c in 3.14.9 Steven Hartman
Next: Re: breaktable checks in dbLexRoutines.c in 3.14.9 Steven Hartman
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: breaktable checks in dbLexRoutines.c in 3.14.9 Steven Hartman
Next: Re: breaktable checks in dbLexRoutines.c in 3.14.9 Steven Hartman
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 
ANJ, 10 Nov 2011 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·