Experimental Physics and
Industrial Control System

Andrew Johnson via Core-talk <[email protected]> · Tue, 23 Apr 2019 17:52:59 -0000

An input link currently has no knowledge of the field to which its data
is going to be written. In some cases (e.g. the printf record) there
*is* no such field in the record, and the code reading the link may pass
a different pointer on each call to getValue() — think double-buffering
of arrays for example. The printf record passes a pointer to an auto
variable on the stack, and the data type it requests can also vary
because it depends on the format string in the FMT field. Thus when an
INP field itself gets a new constant value the generic code in
dbPutLinkValue() can have no way to know where to put that value. As a
result we *cannot* implement a generic solution for this in the core IOC
code (dbAccess.c).

The calcout record type was probably the first to implement the
technique of making its INP fields special(SPC_MOD) and calling
recGblInitConstantLink() from the special() routine; the other synApps
records were developed following its example. Keeping that technique
working is what this bug is all about — we broke it between 3.15 and
3.16. It does require help from the record to implement though, so if we
like this behavior and want it to spread we just have to modify the
other record types to do it. Doing that is outside the scope of this
bug-fix.

I described an alternative approach earlier (have a constant link's
getValue() method return the new value once), but that would still
require changes to the record types, and thinking about it further it
would cause interesting effects to any record type that uses double-
buffering, so I don't recommend this approach. This would also fall
outside the scope of this bug-fix.

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

Title:
  Regression in calcout setting constant links at runtime

Status in EPICS Base:
  In Progress
Status in EPICS Base 7.0 series:
  In Progress

Bug description:
  With the 3.15 branch, writing a literal number to a calcout.INP[A-L]
  field causes the corresponding [A-L] field to be set to that number.
  This works because the calcout record marks the INP fields as
  special(SPC_MOD) and the calcout::special() routine calls
  recGblInitConstantLink() to initialize the corresponding [A-L] field
  from the new link string. I suspect that a number of the synApps
  record types (transform, scalc, acalc etc.) probably use this same
  technique.

  Keenan Lang reported that this doesn't currently work on the 7.0
  branch; the value in the [A-L] field doesn't change, which I have
  confirmed.

  This use of special() to reinitialize constant links is unusual,
  normally putting a literal into a link field after record
  initialization has no effect, but someone who worked on the calcout
  record discovered this way to get it to work.

  I think I know what's going on and how to fix it (change
  dbPutFieldLink() to call dbAddLink() before the second call to
  dbPutSpecial()), but I need to check that this won't break other
  cases.

To manage notifications about this bug go to:
https://bugs.launchpad.net/epics-base/+bug/1824277/+subscriptions

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System