What version of Base is involved?
I did some work related to queuing of processing when an asynchronous
record appears in the middle of a chain, which is applicable to your database.
This appeared in 7.0.2.1.
On 11/20/20 12:01 PM, Hu, Yong via Tech-talk wrote:
> 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://
>
> 1. Simulate beam dump: caput PMStatus-I 1;
> 2. 2-second later, reset PM Status (the reset is too early): caput PMStatus-I 0;
> 3. 17-second later, simulate beam dump again: caput PMStatus-I 1;
> 4. 17-second later, reset PM Status: caput PMStatus-I 0;
>
>
>
> 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:
>
> 1. Should the CA input link CP/CPP have the function of “Cached Puts”?
> 2. Is it a good idea to have “Queued Puts” for EPICS records? AreaDetector is using “queue” for plugins although its queue is for keeping input data.
>
>
>
> Thank you for taking your time to read such a long message. Wish you a safe and Happy Thanksgiving.
>
>
>
> Yong
>
> NSLS-II Controls Group
>
>
>
- Replies:
- Re: calcout record, CP link, Cached Puts Hu, Yong via Tech-talk
- References:
- calcout record, CP link, Cached Puts Hu, Yong via Tech-talk
- Navigate by Date:
- Prev:
Re: asyn connetion to wti Maren Purves via Tech-talk
- Next:
Clean up library upon ioc exit Laurenz Rettig via Tech-talk
- 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
- Navigate by Thread:
- Prev:
calcout record, CP link, Cached Puts Hu, Yong via Tech-talk
- Next:
Re: calcout record, CP link, Cached Puts Hu, Yong via Tech-talk
- 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
|