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: | Proposal: Timestamp records before OUT links |
From: | "Hill, Bruce via Tech-talk" <[email protected]> |
To: | Techtalk <[email protected]> |
Date: | Sat, 13 Apr 2019 05:57:23 +0000 |
An issue was brought up at the recent EPICS Core Developers meeting that warrants soliciting input from the broader EPICS community. Currently EPICS base records with output links call recGblGetTimeStamp() after processing the output links but before FWD links are processed. This can result in stale timestamps if your EPICS database contains record processing chains with output links and TSEL links are used to set timestamps to the timestamp of the event which initiated the chain. An example of this is shown in the attached pdf, courtesy Kukhee Kim at SLAC, and can be seen by running softIoc -d outLinkTimestamp.db and camonitor the records. An event happens, in this example the 1 second SCAN loop, and the calc record processes. An ao record is processed via FLNK and after processing it's OUT link, gets a good timestamp via a TSEL link to the calc record. However, before the ao record updates its timestamp, the ao OUT link writes the value to an ai record which fetches the prior timestamp via a TSEL link to the ao record. A git pull request for this proposed change can be found here: https://github.com/epics-base/epics-base/pull/26#issuecomment-477393831 Without this patch, we see stale timestamps: % camonitor test:{calc,ai,ao} test:calc *** Not connected (PV not found) test:ai *** Not connected (PV not found) test:ao *** Not connected (PV not found) test:calc <undefined> 0 UDF INVALID test:ai <undefined> 0 UDF INVALID test:ao <undefined> 0 UDF INVALID test:calc 2019-04-12 22:50:52.672043 1 test:ai <undefined> 1 test:ao 2019-04-12 22:50:52.672043 1 test:calc 2019-04-12 22:51:02.672028 2 test:ai 2019-04-12 22:50:52.672043 2 test:ao 2019-04-12 22:51:02.672028 2 With this patch applied, camonitor shows the expected timestamps: % camonitor test:{calc,ai,ao} test:calc *** Not connected (PV not found) test:ai *** Not connected (PV not found) test:ao *** Not connected (PV not found) test:calc <undefined> 0 UDF INVALID test:ai <undefined> 0 UDF INVALID test:ao <undefined> 0 UDF INVALID test:calc 2019-04-12 22:54:44.083420 1 test:ai 2019-04-12 22:54:44.083420 1 test:ao 2019-04-12 22:54:44.083420 1 test:calc 2019-04-12 22:54:54.083376 2 test:ai 2019-04-12 22:54:54.083376 2 test:ao 2019-04-12 22:54:54.083376 2 pros:
Comments are solicited and appreciated. Best regards, - Bruce -- Bruce Hill Member Technical Staff SLAC National Accelerator Lab 2575 Sand Hill Road M/S 10 Menlo Park, CA 94025 |
record(calc, "test:calc") { field(INPA, "test:calc.VAL") field(CALC, "A+1") field(SCAN, "10 second") field(FLNK, "test:ao PP") } record(ao, "test:ao") { field(DOL, "test:calc") field(OMSL, "closed_loop") field(SCAN, "Passive") field(TSEL, "test:calc.TIME") field(OUT, "test:ai PP") } record(ai, "test:ai") { field(TSEL, "test:ao.TIME") field(SCAN, "Passive") }
Attachment:
2019_0122 timestamp issue on output record.pdf
Description: 2019_0122 timestamp issue on output record.pdf