Experimental Physics and
Industrial Control System

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