Experimental Physics and
Industrial Control System

"Brian McAllister" <[email protected]> · Fri, 11 Jun 2004 13:59:00 -0400

>>> Dirk Zimoch wrote:

  > All tools including caget and camonitor should honor PREC.

Caget has command line arguments that can be used to specify both format
and precision.  I find that having a default precision rather than using
what's defined in the record is useful, as people frequently neglect to set
the precision and 0 is rarely useful for floating-point numbers.  I would
probably end up creating an alias specifying a format if it used PREC by
default.  Perhaps if one could distinguish between an explicit PREC=0 and
"no PREC defined" it would make sense to honor PREC by default, but that is
not currently possible.

I don't know which version of camonitor you are using, but the one we use
here (which is fairly old) effectively honors PREC, because it always
fetches the value as a string.  Earlier versions fetched the value in
native format and did the format conversion locally.

  > All in all, it was just an idea, how one could define in the record how
  > the value should be shown and not in caget or the adl file. It is more
  > in line with the EPICS philosophy (as I understand it) to configure as
  > much as possible on the record level. A change in cvtFloatToString,
  > etc.  could possibly do it for most applications.

As you quoted:

   * Precision: Precision with which to display floating point numbers.

The key word here (in the discussion) is "DISPLAY".  When a value is
retrieved as a number in native format, PREC correctly has no effect.  The
number is the number, and is not truncated or rounded.  How that number is
displayed should always be controllable by the client, with PREC (like
HOPR/LOPR) as a *suggestion* indicating what the database designer believes
is appropriate, which is used by default if the user doesn't specify
otherwise.

MEDM (and I assume the other display tools) allows the user to display
numbers is whatever format they please, including displaying the same value
in more than one format.  This is a GOOD THING.

The case in which the value is retrieved as a string, with the IOC doing
the formatting, is different.  In this case, PREC should of course be used,
and perhaps the behaviour could be better defined/documented.

>>> Allison, Stephanie wrote:

  > Here is a radical thought - it would be nice to have a new string field
  > (ie, .FMT) that specifies how to display the value as a string.  Then I
  > could set up the format of our vacuums (ie, VALs that should always be
  > displayed using exponential notation) in the database instead of having
  > to override the default display format in each client.  Also, some
  > save/restore tools won't restore the proper values of things like
  > vacuum limits unless you set a ridiculously large PREC.

This I like.  Not only useful when the format conversion is done by the
IOC, but also usable by display tools to default not only the precision and
limits but also format.

----
Brian McAllister                    Controls Programmer/Beam Physicist
[email protected]                        MIT-Bates Linear Accelerator
(617) 253-9537                                           Middleton, MA

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System