After discussion with Till Straumann and Freddie Akeroyd, we found the
following usecases for this feature:
- It's not intuitive that one can get the timestamp (e.g. using caget -a) by getting any field /except/ TIME.
- Getting a 64-bit integer would simplify calculations.
- Getting a double would also simplify calculations, albeit with reduced precision, and is better supported in EPICS. This would make it trivial to e.g. calculate time deltas using the calc record.
- Getting two 32-bit integers is better supported than a 64-bit integer, but is a pain to use. Sometimes, one is only interested in seconds or only nanoseconds, in which case, CA filters could be used to get the desired value.
- Writing to the timestamp: I'm sure there's someone out there who would like to have that, but it's not clear that it's a good idea and how it would interact with TSE and such.
We cannot change the underlying type of the TIME field as that would
break the world. I have looked at two approaches: adding additional
fields to dbCommon, and CA filters.
Adding an additional field could be done as follows:
- Add a UINT64 field named TM64 (or something to that effect).
- This field would contain a copy of the timestamp converted from the TIME field.
- Handle the TIME field like fields with SPC_DBADDR are handled, except instead of calling cvt_dbaddr(), point to the data in TM64. This allows accesing the 64-bit timestamp through the TIME field.
- Advantages:
- Both TIME and TM64 are directly readable.
- UINT64 will gracefully degrade to double and string: calc will work and caget will have full precision in ascii representation.
- Additional fields can be added to serve seconds and nanoseconds separately.
- Drawbacks:
- No human-readable string (but I don't think that's a problem)
- It introduces additional overhead for every single record. This is even more pronounced if more fields are added to provide seconds and nanoseconds separately.
- I see no way to keep the timestamps in sync. One would need to wrap the rset::process() function, but that cannot be done because users outside of EPICS base may call it directly.
To implement this via CA filters, I propose extending the "ts" filter. It already has the right name, even though, given how general the name is, its current behaviour is oddly specific. It currently takes no arguments, so extending it shouldn't be a problem.
Advantages:
- Seems easy to implement with no interference to other parts of the code.
- Very flexible.
- No overhead when not in use.
Drawbacks:
- The TIME field itself would remain inaccessible. It was argued that one /can/ currently get the timestamp, but not in a straightforward way, and seems to me that CA filters are not yet part of users' muscle memory.
--
You received this bug notification because you are a member of EPICS
Core Developers, which is subscribed to EPICS Base.
Matching subscriptions: epics-core-list-subscription
https://bugs.launchpad.net/bugs/1182091
Title:
Make TIME field directly accessible
Status in EPICS Base:
Triaged
Bug description:
Users often request the ability to access the TIME field directly.
It could be provided as an array of 2 32-bit values, possibly with a specific string in ISO-8601 form say.
To manage notifications about this bug go to:
https://bugs.launchpad.net/epics-base/+bug/1182091/+subscriptions
- Navigate by Date:
- Prev:
[Bug 1905159] Re: Fix warnings from recent compiler versions Gabriel Fedel via Core-talk
- Next:
[Bug 1398215] Re: Make output records only write on change Andrew Johnson via Core-talk
- Index:
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:
[Bug 1905159] Re: Fix warnings from recent compiler versions Jerzy Tarasiuk via Core-talk
- Next:
[Bug 1182091] Re: Make TIME field directly accessible Jure Varlec via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
<2021>
2022
2023
2024
|