2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 <2021> 2022 2023 2024 | Index | 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: [Bug 1777768] Re: NPP Put to a pp(TRUE) VAL field doesn't trigger monitors |
From: | "Mooney, Tim M. via Core-talk" <core-talk at aps.anl.gov> |
To: | "core-talk at aps.anl.gov" <core-talk at aps.anl.gov>, Bug 1777768 <1777768 at bugs.launchpad.net> |
Date: | Tue, 13 Jul 2021 21:27:27 +0000 |
I thought the reason the VAL field was only posted by the record was to give the record the ability to refuse a value written to it and not have anyone else notified that the value had been written.
Tim Mooney (mooney at anl.gov) (630)252-5417
Beamline Controls Group (www.aps.anl.gov) Advanced Photon Source, Argonne National Lab From: Core-talk <core-talk-bounces at aps.anl.gov> on behalf of Andrew Johnson via Core-talk <core-talk at aps.anl.gov>
Sent: Tuesday, July 13, 2021 2:26 PM To: core-talk at aps.anl.gov <core-talk at aps.anl.gov> Subject: [Bug 1777768] Re: NPP Put to a pp(TRUE) VAL field doesn't trigger monitors I hope we all agree that database designers need to be able to specify
whether a put through a DB link should trigger processing of the target record or not, hence the PP/NPP flags supported by the DBF_OUTLINK. I don't see any real alternatives to that, a new TPP flag isn't that compelling. The per-field pp(TRUE) mechanism used for CA put operations does decouple the IOCs from their clients. I'm now particularly possessive of that design but it has worked well enough up to now, and it means that EPICS GUIs never needed to know anything about the database they're connecting to, which I see as a good thing. It might be nice if a database designer could configure that behavior on a per-record-field basis, but implementing that could be tricky and/or slow. @Michael Does QSRV default to using the pp(TRUE) value? Do any GUIs that support PVA provide the ability to override the process flag? The isValueField conditional at the end of dbPut() was added so a CA put to a record's VAL field doesn't trigger 2 monitor events, one from dbPut() and the second from the record's monitor() routine called from process(). The first monitor event is suppressed when the target field is VAL and it is marked pp(TRUE) which means a CA put would process the record. My original patch for this undid that suppression if necessary when the put actually comes from a DB link which is NPP. -- You received this bug notification because you are a member of EPICS Core Developers, which is subscribed to EPICS Base. Matching subscriptions: epics-core-list-subscription https://bugs.launchpad.net/bugs/1777768 Title: NPP Put to a pp(TRUE) VAL field doesn't trigger monitors Status in EPICS Base: Incomplete Bug description: There is code in dbAccess.c::dbPut() that calls db_post_events() after writing to a field. This code is conditional, and explicitly avoids posting a monitor if the put was to the record's VAL field and that field is marked pp(TRUE); if the put came from a CA client the record is about to be processed anyway, so this conditional prevents 2 monitor events from being generated by the same put. However if the put was actually from a DB link marked NPP, the above logic is wrong because the record is not about to be processed. This behavior is somewhat obscure, and does catch out database designers (it came up again at APS just today). It is possible for the DB link to call db_post_events() itself in this case, but it isn't obvious whether it should or not. When I add the necessary code the result looks a bit strange because the record's VAL changes but the alarm state and timestamp do not. This could also conflict with the monitor deadband processing as this monitor will happen every time the put occurs and will not update the MLST field. I will attach the necessary code changes to this bug report for the 3.16 branch; earlier branches would need it moving since the modifications are to the DB link type, and I don't think it should go in any earlier than 3.16 anyhow. Opinions please, should this be applied or not? To manage notifications about this bug go to: https://bugs.launchpad.net/epics-base/+bug/1777768/+subscriptions |