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: [EXTERNAL] Re: FLNK doesn't process |
From: | "Pearson, Matthew via Tech-talk" <tech-talk at aps.anl.gov> |
To: | "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
Date: | Tue, 18 Jan 2022 15:38:02 +0000 |
Hi, Another way to answer the original question, at the expense of adding an additional record, is to do this: record(bo, “scanner”) { field(SCAN, “10 second”) field(FLNK, “readback”) } record(ao, “setpoint”) { field(DTYP, “stream”) field(OUT, “@my.proto set() portName”) field(SCAN, “Passive”) field(FLNK, “readback”) } record(ai, “readback”) { field(DTYP, “stream”) field(INP, “@my.proto get() portName”) field(SCAN, “Passive”) } And if you have multiple readbacks then the “scanner” could be a fanout or dfanout. The advantage of the above is that you can use put_callback to set the setpoint and immediately check the readback to see if the value was accepted, like: bash> caput -c setpoint 10.0 bash> caget readback which doesn’t work if you have a CA link involved. Cheers, Matt From: Tech-talk <tech-talk-bounces at aps.anl.gov>
On Behalf Of Ralph Lange via Tech-talk On Tue, 18 Jan 2022 at 12:06, William Kirstaedter via Tech-talk <tech-talk at aps.anl.gov> wrote:
Please note: Targeting local FLNKs to .PROC and making them CA is only required in a few cases:
·
If the target record is scanned periodically.
·
If you need to override the loop protection in EPICS Base.
·
If you want to avoid putting too many records in the same lock set. The regular cases (passive target record, "normal" use case, one-to-one FLNKing) can and should use database records. Using database records is immediate, fast, directly coupled. Basically a call to the target record's process() routine. Using CA to the .PROC field adds queueing, delay, thread switching. Think of it as a loosely coupled triggering of the target record "in the very near future". Cheers, ~Ralph |