Experimental Physics and
Industrial Control System

Andrew Johnson via Core-talk <core-talk at aps.anl.gov> · Mon, 12 Jul 2021 18:01:33 -0000

I had another report of this behavior from an APS developer.

He has an aSub record which is writing a scalar from VALA via a DB link
in OUTA to a passive ai record. He has to set the PP flag on the OUTA
link for his OPI screens to see the change in the ai.VAL field, even
though a caget of that field demonstrates that the put has succeeded. If
he was writing to any field other than VAL there would be no need to set
PP for monitors to fire automatically and the OPI screens to update.

I take Ralph's point that not processing the record results in its
timestamp never getting set and alarms never being checked, which are
good reasons to tell users they should be setting PP. However this is
evidently a cause for user confusion. Before I withdraw this bug is
there any way we can help users to understand the current behavior
better? The confusion is caused by the isValueField conditional towards
the end of dbPut():

    if (precord->mlis.count &&
        !(isValueField && pfldDes->process_passive))
        db_post_events(precord, pfieldsave, DBE_VALUE | DBE_LOG);

I note that DB links don't have any way to say "follow the target field's pp() setting" although that could be implemented relatively easily with a new (RPP or TPP?) link flag. Would it be worth adding something like that? I might even be inclined to make that the default in the absence of either PP/NPP flag, but doing so might need a warning at load-time to avoid breaking too many existing databases.

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System