Experimental Physics and
| |||||||||||||||||
|
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
| ||||||||||||||||
ANJ, 10 Nov 2011 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing · |