EPICS Controls Argonne National Laboratory

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  <20172018  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  <20172018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Puzzled with lockset(?) problem
From: "Mooney, Tim M." <[email protected]>
To: Dirk Zimoch <[email protected]>, EPICS <[email protected]>
Date: Mon, 18 Dec 2017 18:34:25 +0000

Hi Dirk,


I don't understand what's happening, but I have a clue:  If you write to "mode" directly from an aSub output link, the database behaves as it should.


Tim Mooney ([email protected]) (630)252-5417
Beamline Controls Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab


From: [email protected] <[email protected]> on behalf of Dirk Zimoch <[email protected]>
Sent: Friday, December 15, 2017 10:02:52 AM
To: EPICS
Subject: Puzzled with lockset(?) problem
 
Hi Folks,

A colleague puzzled me with a db that shows surprising behavior.

An aSub record is triggered periodically though a CP input link. It
looks up if it needs re-initialization (the user can press a button to
request that). If yes it does an additional calculation. After
processing it resets the record that requested the re-initialization.

See the attached .db file.

Usually when the user presses the button to re-initialize, the aSub does
the additional calculation once and then goes back to normal processing.

But the calculation may may take a bit too long -- longer than the rate
of the CP input link monitors. In that case, the record never leaves
initialization mode!

I have simulated the slow calculation with the attached subroutine code
which simply waits. (I know that is is a bad idea to wait in a
synchronous subroutine. The original code does not wait but calculates.)

I think that this is an effect of lock sets because the "mode" record is
as well input being processed by a caput as well as output of the aSub
record. But is this the intended behavior?

The CP monitor finds the record busy (PACT=1) and arranges for
re-processing when the record is done. But should not the FLNK be
processed and the mode record go to 1 before the aSub runs again?

Any idea how to fix this? Is it necessary to make the subroutine
asynchonous? Making the links from and to "mode" CA links does not fix
it. Scanning the aSub itself with ".1 second" does not show the strange
behavior, it simply delays the scan thread.

Puzzle for the weekend...
Dirk

References:
Puzzled with lockset(?) problem Dirk Zimoch

Navigate by Date:
Prev: Re: Puzzled with lockset(?) problem Dirk Zimoch
Next: aCalcout AVAL monitors Bruno Martins
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Puzzled with lockset(?) problem Dirk Zimoch
Next: Re: Puzzled with lockset(?) problem Michael Davidsaver
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
ANJ, 21 Dec 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·