On 13.09.2013 01:56, Zelazny, Michael Stanley wrote:
If the db library hard codes the time field, it is reasonable for autosave to similarly hard code the time field?
Not really.
Well, maybe.
Pointing TSEL to other fields (like .VAL) is valid. The obtained value
is interpreted as an event number, and the timestamp of the last
occurence of that event is being used. (Requires an event system driver.)
The only way autoSaveRestore could find out if that link to .VAL was put
there intentionally or if it was converted from a link to .TIME would be
looking at the internal flag of the pv_link. (ppv_link->pvlMask &
pvlOptTSELisTime)
I don't know ... that looks a lot like working around a dirty hack with
another dirty hack.
Maybe using a new magic number for TSE would be a cleaner solution: "-3"
= use timestamp of record that TSEL points to.
That would make things a lot more obvious and autoSaveRestore would just
work.
~Ralph
________________________________________
From: [email protected] [[email protected]] On Behalf Of Ralph Lange [[email protected]]
Sent: Wednesday, September 11, 2013 7:30 AM
To: EPICS Tech-Talk
Subject: Re: TSEL question
[snip]
I.e., the link in the database is set up pointing to the VAL field, the
db library hard-codes the time field in recGblGetTimeStamp().
Cheers,
~Ralph
- Replies:
- Re: TSEL question Ralph Lange
- Navigate by Date:
- Prev:
Re: macLib semantics should be documented somewhere Benjamin Franksen
- Next:
Re: TSEL question Ralph Lange
- 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 641365] Re: Incorporate macLibREADME text into 19.16 Andrew Johnson
- Next:
Re: TSEL question Ralph Lange
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
<2013>
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|