Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
<== Date ==> <== Thread ==>

Subject: Re: bug in break-point table conversion
From: Andrew Johnson <anj@aps.anl.gov>
To: "D. Peter Siddons" <siddons@bnl.gov>
Cc: Rolf Keitel <rolf@triumf.ca>, tech_talk <tech-talk@aps.anl.gov>
Date: Wed, 17 May 2006 17:51:03 -0500
D. Peter Siddons wrote:

I'm not even sure when one would use the backward conversion. Isn't it always used forwards?

The ai record uses cvtRawToEngBpt(), but the ao record actually calls both cvtRawToEngBpt() and cvtEngToRawBpt(), since some device support layers can read the current output value from hardware registers at reboot time and convert this back to the correct engineering units value, thus supporting bumpless reboot for those channels.


Note that it is possible (if unusual) to use the same breakpoint table for both input and output conversions.

I also wrote privately to Rolf yesterday; I'll incorporate our conversation back into the public list in this reply:

Rolf Keitel wrote:
Andrew Johnson wrote:

Hi Rolf,

Rolf Keitel wrote:

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).

If I read it properly the existing code only works if both the raw and engineering units values increase as you go down the table - otherwise you probably end up using the wrong slope for the interpolation process. However I haven't confirmed that properly so feel free to contradict me.

That is correct. If the slope is negative, the algorithm will always pick the first pair of breakpoints in the table and extrapolate linearly from there. (I checked this only for the eng>>raw conversion, but the algorithms are identical).

Since the algorithms are identical with just eng and raw swapped, I claim that we do need to make equivalent changes to the cvtRawToEngBpt() routine - the two are mirror images of each other, the only difference being whether you divide or multiply by the slope.


I agree that we should be able to support curves with negative slopes, but I was trying to avoid spending much time on adding that support myself. However while writing this reply I added the necessary tests to the parser routines to check that the engineering units values always increase and that the breaktable slopes always have the same sign.

I'm not sure yet whether you've completely converted the cvtBpt.c file, since there's another routine in there for conversions in the reverse direction - did you decide that cvtRawToEngBpt() already works with negative slopes, or not look at it at all? I don't think it should work..

I made only modifications to the cvtEngToRawBpt(), working from the assumption, that one can always arrange the table to use ascending raw values, in which case the cvtRawToEngBpt() works. Then you only have to worry about the negative slope in the engineering series for the conversion eng >> raw (We never used an EPICS tool to generate breakpoint tables).
So the parser could flatly reject descending raw sequences.

I'm not convinced that's right; the sign of the slope depends on both the sign of the difference between adjacent both engineering and raw values. The calculation does this:
slope[i] = (eng[i+1] - eng[i]) / (raw[i+1] - raw[i]);
It makes no difference to the slope value if you swap the order of the samples in the interval, as you'll just change the sign of both the numerator and denominator.


That same calculation is used whether you're going to be calling cvtRawToEngBpt() or cvtEngToRawBpt(), and in fact the parser doesn't know which of the two you're going to use the table with.

I think one should leave everything else up to the breakpoint table designer. There may even be some value of allowing both slope signs in the engineering sequence, as long as the slope in the raw series is always positive. This would allow for analogue input records to handle such things (although the same conversion in an output record would fail due to ambiguity).

There is only one slope calculated as above for each interval, which is used for both raw -> eng and eng -> raw calculations, so your sentence "as long as the slope in the raw series is always positive" doesn't make sense.


Ok, I duplicated your example in the other routine, and did some other restructuring to reduce the memory allocation requirements of each table. I haven't completed testing the result yet, but I'm working on it.

- Andrew
--
There is no S in exprexxo.

References:
bug in break-point table conversion Rolf Keitel
Re: bug in break-point table conversion D. Peter Siddons
Re: bug in break-point table conversion Andrew Johnson
Re: bug in break-point table conversion Rolf Keitel
Re: bug in break-point table conversion D. Peter Siddons

Navigate by Date:
Prev: RE: Document, visualize SNL code? Al Honey
Next: EPICS Training Course: date change to Sept 11-15th 2006 Philip Taylor
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
Navigate by Thread:
Prev: Re: bug in break-point table conversion Rolf Keitel
Next: Re: bug in break-point table conversion Benjamin Franksen
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·