EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  <20042005  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  <20042005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: PREC
From: Andrew Johnson <[email protected]>
To: Pete R Jemian <[email protected]>
Cc: TECHTALK <[email protected]>
Date: Fri, 11 Jun 2004 14:37:17 -0500
Pete R Jemian wrote:

But someone can always come up with a standard situation where a single format specifier for all fields is problematic. How can we handle some fields differently from others?

This can already be done for the precision value, if it is implemented in the record support code - there is no requirement that there be just one field for setting precision, but I'm not aware of any records that have more than one; many record types don't have a PREC field at all. There's nothing stopping something like the motor record from providing a different precision for some fields than it does for others. Here's how:


There is a routine in the record support, called get_precision() which is responsible for returning the precision value for any record field. Most record types just check if the field they're being asked about is VAL and if it is they return PREC; if not they just ask recGblGetPrec() which sets a default for the particular field type. Any record that needs multiple precision settings can just test for multiple field addresses and return different precision values as it sees appropriate - presumably it would group different fields together and have a precision field for each group.

I agree that Stephanie's .FMT would be a nice idea if we were starting from scratch, but right now we would have to replace the numeric precision field that currently exists in all of the struct dbr_gr_<xxx> definitions in cadef.h and we'd have to modify the CA protocol and all of the clients that use it. In the future we'll be able to do that if we decide it's the best solution, but I can't really see us moving away from a single number defining precision for quite a while.

We already have an implementation that copes with multiple fields if we can agree to redefine what the precision value actually means. It would probably be simplest and best for the next major release branch (R3.15) to change the definition of precision to be that of the ANSI C standard's %g format string - does anyone particularly object to that idea?

- Andrew
--
Dear God, I didn't think orange went with purple until I saw
the sunset you made last night.  That was really cool. - Caro


References:
RE: PREC Pete R Jemian

Navigate by Date:
Prev: Re: Initializing a record VAL field with a constant Marty Kraimer
Next: RE: Initializing a record VAL field with a constant Allison, Stephanie
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  <20042005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: PREC Pete R Jemian
Next: JCA maintainers John Maclean
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  <20042005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·