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: | calcout record, CP link, Cached Puts |
From: | "Hu, Yong via Tech-talk" <tech-talk at aps.anl.gov> |
To: | "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
Date: | Fri, 20 Nov 2020 20:01:24 +0000 |
Hello everyone, I have an application (saving postmortem data after beam dump) which uses simplified records as below: record(bi, "PMStatus-I") { field(DESC,"Post-Mortem status") field(ZNAM,"PM Ready") field(ONAM,"PM Detected") } record(calcout,"PM-Calc_") { field(INPA,"PMStatus-I CP") field(CALC,"A") field(OOPT,"Transition To Non-zero") field(OUT, "PM-Cmd PP") field(ODLY, "15") field(RPRO,"1") field(MDEL,"-1") } record(bo, "PM-Cmd") { #field(DTYP,"Launcher") #field(OUT, "@python /epics/iocs/postmortem/save_pmdata.py") field(ZNAM,"Idle") field(ONAM,"Setting") field(HIGH,"1") } The logic in the records above: whenever “PMStatus-I” is changed from 0 to 1 meaning the beam is dumped, the calcout record waits for ODLY seconds, then it writes to "PM-Cmd", which in turn executes a Python
script. For the purpose of simple and easy tests (you can try it by yourself), ODLY is set to 15 and DTYP and OUT are commented out in the bo record. The actual ODLY in my application is 180-second. After beam dump, “PMStatus-I” becomes 1. Then after the machine
is ready for injection again, our operators manually reset “PMStatus-I” to 0. My application works most of the time, but occasionally it fails to execute the Python script after beam dump. After a deep investigation, it turns out the problem occurs whenever
our operators reset “PMStatus-I” to 0 too quickly (before the 180-second ODLY expires). Sorry for the long story. Let’s back to the simplified records above. I use this simple Python script to test it out: $ cat test1.py #!/usr/bin/python import cothread from cothread.catools import caput caput('PMStatus-I', 1) cothread.Sleep(2) caput('PMStatus-I', 0) cothread.Sleep(17) caput('PMStatus-I', 1) cothread.Sleep(17) caput('PMStatus-I', 0) Basically, the script performs this:
This is the result, which reproduces the problem: two beam dumps, but the record “PM-Cmd” only gets processed once.
camonitor -n PM-Cmd PM-Calc_ PMStatus-I PM-Calc_.DLYA PM-Calc_.RPRO PM-Calc_.MDEL PM-Calc_.PACT PM-Cmd <undefined> 0 UDF INVALID PM-Calc_ 2020-11-20 11:32:41.850265 0
PMStatus-I <undefined> 0 UDF INVALID PM-Calc_.DLYA 2020-11-20 11:32:41.850265 0
PM-Calc_.RPRO 2020-11-20 11:32:41.850265 0
PM-Calc_.MDEL 2020-11-20 11:32:41.850265 -1
PM-Calc_.PACT 2020-11-20 12:17:15.011557 0 PMStatus-I 2020-11-20 11:39:44.310406 1
PM-Calc_.DLYA 2020-11-20 11:39:44.310465 1
PMStatus-I 2020-11-20 11:39:46.311319 0
PM-Calc_.DLYA 2020-11-20 11:39:59.305587 0
PM-Cmd 2020-11-20 11:39:59.305599 1
PM-Calc_ 2020-11-20 11:39:59.305587 1
PM-Cmd 2020-11-20 11:40:00.300696 0
PMStatus-I 2020-11-20 11:40:03.325023 1
PM-Calc_ 2020-11-20 11:40:03.325097 1
PMStatus-I 2020-11-20 11:40:20.336303 0
PM-Calc_ 2020-11-20 11:40:20.336354 0 In the document AppDevGuide, it says: CP - Forces the link to be a channel access link and also requests that the record containing the link be processed whenever a monitor occurs. In the step #2, “PMStatus-I”
is changed from 1 to 0, which I thought will cause the calcout record “PM-Calc_” to be processed again later on although the PACT of “PM-Calc_” is still TRUE right now. However, it does not happen as I thought: “PM-Calc_” does not change to 0 after “PM-Cmd”
gets processed. If I add “caput PM-Calc_.PROC 1” in step #2 after “caput PMStatus-I 0”, then everything works: the record “PM-Cmd” gets processed twice after two simulated beam dumps. So, “caput PM-Calc_.PROC 1” seems to be “Cached Puts” as said in the AppDevGuide. My questions:
Thank you for taking your time to read such a long message. Wish you a safe and Happy Thanksgiving. Yong NSLS-II Controls Group |