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: bug in break-point table conversion |
From: | "D. Peter Siddons" <[email protected]> |
To: | Rolf Keitel <[email protected]> |
Cc: | Andrew Johnson <[email protected]>, tech_talk <[email protected]> |
Date: | Wed, 17 May 2006 09:12:06 -0400 |
Andrew,
I am not sure if I understand your message correctly. Rejecting negative slopes (in the second column) of the breakpoint table would be too limiting. One can always arrange the raw value sequence in ascending order. The engineering sequence slope is then determined by your sensor (in our case Si cryo-diodes).
IMHO one doesn't have to go overboard with reengineering, as breakpoint tables are not really used "on the fly".
Documenting the requirements of monotonous curves in both columns, a positive slope in the raw column and fixing the code for the backward conversion would be sufficient for me.
Of course, dynamically reloading of breakpoint tables at run-time would be nice.
- rolf -
Andrew Johnson wrote:D. Peter Siddons wrote:I had also just run into this. It is also a bug in the makeBpt program to generate a table from raw data. It produces nonsense if the raw ADC values are in decreasing order and the engineering values are increasing. I didn't try it with positive slope but reversed data order. I thought that simply reversing the table order fixed it, but apparently not.
Rolf Keitel wrote:
There is a problem with break-point table conversion from engineering to raw values ( function cvtEngToRawBpt in file cvtBpt.c).
The function returns incorrect results, if the breakpoint table has negative slopes, i.e. if engineering values decrease with increasing raw values.
I couldn't find anything in the documentation when I looked briefly the other day, but I don't think the present breakpoint table code was ever supposed to work with negative slopes. Given the limitations of the existing code though it really ought to check its inputs properly and refuse to load a breakpoint table that slopes downwards.
Any replacement code that permits negative slopes should reject curves that are not continuously increasing or decreasing but have local minima or maxima - I have no idea what the existing code does with such curves, but I doubt that it's pretty. We would also like to be able to reload breakpoint tables at runtime (which I believe Benjamin Fransken implemented for BESSY but this isn't available in the official release).
Any offers to do a proper re-engineering of this (fairly self-contained) area of functionality in EPICS Base? If no-one offers I'll try to put in the positive slope test, but if a site needs more than that it'll have to donate some effort towards implementing it.
- Andrew