EPICS Re: [EXTERNAL] Re: FLNK doesn't process

Experimental Physics and Industrial Control System

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 ==>

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:

Ralph Lange via Tech-talk <tech-talk at aps.anl.gov>

To:

EPICS Tech Talk <tech-talk at aps.anl.gov>

Date:

Tue, 18 Jan 2022 21:45:13 +0100

Hi Matt,

On Tue, 18 Jan 2022 at 16:38, Pearson, Matthew via Tech-talk <tech-talk at aps.anl.gov> wrote:

Hi,

Another way to answer the original question, at the expense of adding an additional record, is to do this:

[...]

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.

Careful.

Your database is perfectly fine. But your Stream record 'setpoint' processes asynchronously, and in that case put_callback returns after the first phase of record processing, i.e. after the request to write the value has been issued. If your device is slow (and you're typing fast) you can execute the 'caget' and fetch the old value before the 'readback' record has been processed. (Add a wait command inside the write protocol to play with this.)

Things are different when you set up a camonitor for 'readback'. In that case, the 'setpoint's FLNK processes the 'readback' record, and after the second phase of that processing, the monitor update will be sent.

Asynchronously processing records are tricky. FLNK and monitors (i.e., CP input links) are your friends, as they fire after the second phase.

The get, put and put_callback operations return after the first phase and may lead to less robust (timing/load dependent) operation.

Cheers,
~Ralph

References:

FLNK doesn't process Randall Cayford via Tech-talk

Re: FLNK doesn't process Hu, Yong via Tech-talk

Re: FLNK doesn't process Randall Cayford via Tech-talk

Re: FLNK doesn't process William Kirstaedter via Tech-talk

Re: FLNK doesn't process Ralph Lange via Tech-talk

RE: [EXTERNAL] Re: FLNK doesn't process Pearson, Matthew via Tech-talk