Experimental Physics and
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
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".
The spikes show an error at intervals of .1875.
-9.9187, -9.7312, -9.5437, etc.
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.
Pyramid Technical Consultants, Inc.
|ANJ, 17 Dec 2015||
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·