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: | Re: TSEL question |
From: | Ralph Lange <[email protected]> |
To: | EPICS Tech-Talk <[email protected]> |
Cc: | EPICS Core-Talk <[email protected]> |
Date: | Fri, 13 Sep 2013 16:47:09 +0200 |
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