Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: Re: Floating point problems is CA?
From: Jeremy Iken <jiken@ptcusa.com>
To: Mark Rivers <rivers@cars.uchicago.edu>
Cc: "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: Fri, 31 Oct 2014 15:59:57 -0400
I am just using the portable CA server, on Windows and Linux.

On Fri, Oct 31, 2014 at 9:11 AM, Mark Rivers <rivers@cars.uchicago.edu> wrote:
Does this happen only in the portable CA server? Have you tested with an IOC?

Mark

Sent from my iPhone

On Oct 30, 2014, at 9:50 AM, Jeremy Iken <jiken@ptcusa.com<mailto:jiken@ptcusa.com>> wrote:

Hi all,

My company has been using Epics Channel Access Server to great success.
Most everything has been working well for many months.
However, recently we realized weird behavior when setting certain float values.

I first initialize an Epics single-precision floating point PV:
dataGdd = new gddScalar (gddAppType_value,aitEnumFloat32)

I then am able to set it through an Epics client. Here I use some simple PyEpics:

///
from epics import caget, caput
caput('analog_out_wire',-9.9187)
print caget('analog_out_wire')
///

Now, you would expect this to print -9.9187.
However, it prints out -9.935!


Other values work fine.
For example, when setting -9.9184 or -9.9190, it gets the value exactly.

Why can it not set -9.9187 correctly?
(I found the exact same error using C# and CSS, so it is not the fault of the client)

My colleague made this graph to show the difference between what he "puts" and what he "gets".
http://i.imgur.com/Y0DAFU4.jpg

The spikes show an error at intervals of .1875.
-9.9187, -9.7312, -9.5437, etc.
Weird.
This consistent loss of precision is not reasonable for our needs.

In my epicscas.cpp write() function:
caStatus epicspv::write(const casCtx &, const gdd & value)
I noticed that Epics was receiving a value of -9.935 (The wrong value!)
It is not the readback, but the setting of the value is somehow incorrect.
There may be some translation problem in EpicsCA, which I am not prepared to debug.

If I caput() a double precision float (in C#), the error would disappear.
As a workaround, I changed my PVs to 64bit floats and fixed the problem for now, as long as I use doubles instead of floats.

We would like to use 32bit floats in the future and would be interested in finding out why they don't work correctly. This issue may be causing problems for others using CA as well.

Hopefully someone can shed some lights on my odd findings.

Thanks,
Jeremy



Jeremy Iken
Software Engineer
Pyramid Technical Consultants, Inc.
http://ptcusa.com/


References:
Floating point problems is CA? Jeremy Iken
Re: Floating point problems is CA? Mark Rivers

Navigate by Date:
Prev: Re: Interface Labview and EPICS Dale L. Brewe
Next: Re: galil softIOC lose the galil controller Heinz Junkes
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019 
Navigate by Thread:
Prev: Re: Floating point problems is CA? Mark Rivers
Next: Disable database question Elmer Pensack
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  <20142015  2016  2017  2018  2019 
ANJ, 17 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·