EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: calcout record precision
From: Andrew Johnson <[email protected]>
To: Tim Mooney <[email protected]>
Cc: Core-Talk <[email protected]>
Date: Wed, 19 May 2010 16:38:17 -0500
Hi Tim,

On Wednesday 19 May 2010 15:25:26 Tim Mooney wrote:
> Andrew,  I just noticed that the calcout record displays
> all numeric fields except VAL as though PREC were 0.  It
> looks like code changed in 3.14.10, or maybe earlier, to
> let recGblGetPrec() choose a precision based on the field
> type, but recGblGetPrec() doesn't do this.  recGblGetPrec()
> expects the caller to have chosen a precision for floats,
> and merely restricts it to a reasonable range.

>From what I can see, that dates back to before R3.14.9, to a change I made in 
October 2006, which I agree was wrong (I broke the calc record similarly).  
However I don't believe the way recGblGetPrec() is used in the other record 
types really makes much sense either; they actually implement this:

 * For VAL or some other small list of fields, the precision used
   is read directly from PREC.
 * For any other double or float fields, the precision used will be
   the value of PREC but clipped to the range 0-15.
 * For any integer fields, the precision is zero.

As you said above, recGblGetPrec() is merely doing the clipping to the range 
relevant for the field type (but it ought to be more like 0-7 for floats).  
The name is wrong, it should be more like recGblLimitPrec().  It doesn't seem 
to make much sense to only call it for the non-VAL fields though, we should be 
calling it for all fields.

I suggest that for all record types that have one, the get_precision() routine 
should really look like this (modulo the type name and cast for prec):

static long get_precision(DBADDR *paddr, long *precision)
{
    aoRecord	*prec = (aoRecord *)paddr->precord;

    *precision = prec->prec;
    recGblGetPrec(paddr, precision);
    return 0;
}

The only reason to have conditionals in that routine would be if your record 
type had more than one PREC field, which would be completely legal although I 
don't know of any that do.

Comments?

- Andrew
-- 
The best FOSS code is written to be read by other humans -- Harald Welte



Replies:
Re: calcout record precision Tim Mooney

Navigate by Date:
Prev: sequencer beta release Benjamin Franksen
Next: Re: calcout record precision Tim Mooney
Index: 2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: sequencer beta release Ben Franksen
Next: Re: calcout record precision Tim Mooney
Index: 2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·