Re: bug in break-point table conversion

[Andrew Johnson <anj@aps.anl.gov>]

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.