EPICS Home EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

Format page
for printing


Search Tech-talk
1994  1995  1996  1997  1998  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  1997  1998  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: int64in record not sending monitors for larger value changes
From: "Kasemir, Kay via Tech-talk" <tech-talk at aps.anl.gov>
To: "'tech-talk at aps.anl.gov'" <tech-talk at aps.anl.gov>
Date: Thu, 29 Jul 2021 15:29:25 +0000
Hi:

I'm trying to use the relatively new 64 bit records in EPICS base.
I understand that Channel Access doesn't fully support them, the 64 bit integer is transferred as a double, so small changes in large numbers get truncated. I'm not sure if that fully explains the observed behavior, though.

Example record, executed with `softIocPVA`:

record(int64in, "sixtyfour")
{
   field(PINI, "YES")
}

Writing a few values within bash, using its support for converting hex to decimal:

caput sixtyfour $(( 16#FF ))
Old : sixtyfour                      0
New : sixtyfour                      255

caput sixtyfour $(( 16#87654321 ))
Old : sixtyfour                      255
New : sixtyfour                      2.27156e+09

caput sixtyfour $(( 16#32187654321 ))
Old : sixtyfour                      2.27156e+09
New : sixtyfour                      3.44254e+12

Note how the "New :" read-back of the written value looks OK.

The output of 'camonitor sixtyfour', however, stops updating as the value grows beyond 0x87654321:
sixtyfour                      2021-07-29 10:59:04.516933 0  
sixtyfour                      2021-07-29 10:59:32.500969 255  
sixtyfour                      2021-07-29 10:59:39.130877 2.27156e+09  

Same with the output of 'pvmonitor sixtyfour', just slightly different formatting:
sixtyfour 2021-07-29 10:59:04.517  0
sixtyfour 2021-07-29 10:59:32.501  255
sixtyfour 2021-07-29 10:59:39.131  2271560481

If I stop & restart the monitors, they see the correct value:
camonitor sixtyfour
sixtyfour                      2021-07-29 11:00:07.627927 3.44254e+12  

pvmonitor sixtyfour
sixtyfour 2021-07-29 11:00:07.628  3442540364577

.. but again they're stuck there when I 'caput $(( 16#87654321 ))', the smaller value.

I don't think it's a rounding/truncation error from the conversion to double, because floating point 2.27156e+09 !=  3.44254e+12
This is with R7.0.4.1.

Thanks,
Kay
Replies:
Re: int64in record not sending monitors for larger value changes Kasemir, Kay via Tech-talk
Navigate by Date:
Prev: Re: Arbitrary rotation angle with areaDetector Plugin Michael Davidsaver via Tech-talk
Next: Re: int64in record not sending monitors for larger value changes Kasemir, Kay via Tech-talk
Index: 1994  1995  1996  1997  1998  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: RE: Arbitrary rotation angle with areaDetector Plugin Mark Rivers via Tech-talk
Next: Re: int64in record not sending monitors for larger value changes Kasemir, Kay via Tech-talk
Index: 1994  1995  1996  1997  1998  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, 29 Jul 2021 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·