EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  <20072008  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  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: breaktable checks in dbLexRoutines.c in 3.14.9
From: Steven Hartman <[email protected]>
To: EPICS Tech Talk <[email protected]>
Date: Fri, 10 Aug 2007 14:12:47 -0400 (EDT)
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.

In function dbBreakBody() (lines 872-877):
	/* Compute slopes */
	. . .
	if (i == 0) {
		down = (slope < 0);
	} else if (down != (slope < 0)) {
		yyerrorAbort("breaktable: curve slope changes sign");
		return;
	}



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.

Properly, the table should be rejected if the raw values are non-monotonic
and the table is to be used with cvtRawToEngBpt(), or if the engineering
values are non-monotonic and the table is to be used with
cvtEngToRawBpt().  However, I don't think such a check can be made at the
point when dbBreakBody() is called and doing it at run time isn't so
useful. 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).


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). Sorry I missed this when it was discussed on
tech-talk before it was added to base.

Thanks,
-- 
Steve Hartman
[email protected] || 919-660-2650
Duke Free Electron Laser Laboratory

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

Navigate by Date:
Prev: 1785-ENET Device Support James B. Stevens
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  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: 1785-ENET Device Support James B. Stevens
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  <20072008  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 ·