EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  <19971998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  <19971998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: get_precision problem
From: Richard Dickson <[email protected]>
To: [email protected]
Date: Fri, 09 May 1997 17:18:20 EDT
--- Begin Message ---
    I would like to pose some questions regarding a problem we have
had at TJNAF.  I apologize that my description may be a little
lengthy.  We are using version 3.12.2.
    TJNAF uses a locally developed record whose get_precision function
relies on the passed paddr->pfield to point to the field for which
precision is being requested.  A comparison is made between this pointer
and known locations for certain fields within passed *paddr->precord in
an attempt to isolate the field of interest.  This technique fails for
calls made by dbGet as a result of Channel Access read_reply event
processing for process variables of a type small enough to be value
queued when the event is posted.  This is due to dbGet overwriting
the event's paddr->pfield with the address of the event's value queue
entry, thus making any field pointer comparisons fail.  TJNAF's
record attempts to punt when these comparisons fail by calling
recGblGetPrecision, which unfortunately does nothing for DBF_FLOAT
and DBF_DOUBLE types (in 3.12.2).  The end result in our case is
that when a CA client posts a monitor on a variable of one of
these types with a request type of DBR_STRING (or any of its closely
related string relatives), a call is made to cvtDoubleToString
with a precision value of whatever happened to be on the stack
frame after the failed recGblGetPrecision call.  If cvtDoubleToString
is called with a precision of 3000, 3000 ASCII zeros (0x30) will be
output by the conversion.  The first sign of this is usually that
the client->send.stk index assumes the value 0x30303030.  Not good. 
I notice that this problem is somewhat reduced with 3.13 because
recGblGetPrecision now does something for DBF_FLOAT and DBF_DOUBLE.
However, our record's get_precision still will fail to generate
the desired effect of field specific precision values during CA
event handling.
     My questions are:  Is this method of determining precision
within a record purposefully illegal?  Will anything be different
with 3.13 (I can't seem to find dbLink.c to see for myself)?  If
not, is there any way of doing the same thing with other means?

Thanks,

Richard Dickson
Computer Sciences Corp.
Thomas Jefferson National Accelerator Facility
[email protected]
(757)269-5082

--- End Message ---

Replies:
Re: get_precision problem Marty Kraimer

Navigate by Date:
Prev: Agenda for the PAC Training Bob Dalesio
Next: Re: get_precision problem Marty Kraimer
Index: 1994  1995  1996  <19971998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Agenda for the PAC Training Bob Dalesio
Next: Re: get_precision problem Marty Kraimer
Index: 1994  1995  1996  <19971998  1999  2000  2001  2002  2003  2004  2005  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 ·