Experimental Physics and
Industrial Control System

Andrew Johnson via Core-talk <core-talk at aps.anl.gov> · Tue, 13 Jul 2021 22:29:56 -0000

Tim Mooney wrote:

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

That could very well have been the original reasoning, it looks like
puts to the VAL field have behaved like that since the very earliest
commits I have access to (1990).

I now accept that the existing behavior is correct, but it is confusing
to users that DB puts to the VAL field behave differently than to every
other field.

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