| 2002 2003 2004 2005 2006 2007 2008 <2009> 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 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: | Re: wrong timestamps in monitors |
| From: | Ralph Lange <[email protected]> |
| To: | EPICS Core Talk <[email protected]> |
| Date: | Thu, 29 Jan 2009 15:42:12 +0100 |
Hi,One more aspect of this issue: currently the record timestamp is put on all PVs that belong to the record, even though CA has no concept of a record that would match this relation.
So - why not put this on the list of possible work packages for the next codeathon?
Definitely something worth to be fixed, changing a behaviour that no one should rely on (does someone?), and there are ways to improve this that do not need a lot of changes in the code once we agree on how this should be handled.
What do you think? Ralph On 29.01.2009 14:46 Benjamin Franksen wrote:
Hi,I think this is a known issue, it is at least as old as 3.13.9. EPICS posts CA events when a non-VAL fields get written to, and it does so independently of record support. There are two cases:- If the field does not have the PP property, then the record is not processed as a result of the put, and the CA event is posted with the old timestamp.- If the field /does/ have the PP property, then the record gets processed as a result of the put, which woudl update the record's timestamp, but processing comes /after/ EPICS base posts the event, thus the event has the wrong (old) timestamp.It should be clear that this means one should /not/ trust the history of value changes as e.g. reported by the channel archiver (or simply the output of camonitor) whenever the PV in question references a non-VAL field. At least not w.r.t. the reported timestamps.Is this going to be addressed any time soon? Cheers Ben