Re: Change input links run-time in a db

[Tim Mooney <mooney@aps.anl.gov>]

Maren, It's true that most of the things you can accomplish by
changing a link value could also have been accomplished by a
suitably prepared database, which contained hard-wired links to
the values you might want, and a means of selecting which value
is to be used.  A database developer who knows in advance what
values might be needed at run time can work wonders with links
and switches.

However, a user at runtime can't do squat, unless the database
developer has worked the particular wonder that is required.
Our users are, on average, smarter than we are, and we've found
that they're going to want things we'd never think of in advance.
Also, we don't always communicate with them as well as everyone
would like, so giving them tools to fend for themselves has been
a good strategy for keeping them happy, and for giving us enough
breathing room to focus on generic requirements, rather than on
the horde of specific uses that might come up.

In many of our applications, the database developer has no clue
to what specific use a database will be put.  The example that
originally motivated retargetable links is the scan record -- one
clearly does not want to specify at boot time all the things that
might ever be scanned, because the list would include all numeric
PV's in all databases in all ioc's accessible to the record.

Ick.

Since the ice was broken, we've found many other applications that
can benefit from retargetable links.  The first applications were
calc records whose input links could be changed, which allowed
users to choose and modify at runtime what arithmetic combination
of PV values they wanted to reduce to experimentally relevant
numbers.  The next was calc records whose output links could also
be changed, which allowed users to construct slow feedback loops
at run time.

Once retargetable links became firmly entrenched, we started
constructing abstract databases, whose functions were separated
from their targets.  For example, the rampTweak database permits
a user to decide at runtime what knob (e.g., magnetic field,
detector-bias voltage, temperature, etc.) they'd like to vary
slowly over time.  This permits us to implement things simply,
without all the bells and whistles that might eventually be
required, because we can always add the extra stuff quickly at
runtime, even if the user in need doesn't want to, or know how
to, do it.

So, yes, I'd say there is a good reason to want to change link
fields at runtime, even though there is probably no single change
that could not have been forseen and prepared for in advance using
other techniques.

Maren Purves wrote:
> Ulrik, Tim,
>
> my first reaction was: why do you want to do this
> anyway?
>
> Can't you just feed both channels, and a "switch",
> into a calc record or some such and switch values?
> Is there a good reason to actually switch the input
> _channel_ rather than just the value?
>
> Aloha,
> Maren
>
> Tim Mooney wrote:
> > Dear folks,  Changing links at runtime has to be done via Channel Access.
> > This is documented in the App Dev Guide (15.5 Runtime Link Modification).
> > The reason isn't documented there (or at least I haven't found it) but
> > anyway it's because lock sets have to be recalculated, and you can't
> > do that while you're running under the protection of a lock set that's
> > going to be recalculated.

--
Tim Mooney (mooney@aps.anl.gov) (630)252-5417
Beamline Controls & Data Acquisition Group
Advanced Photon Source, Argonne National Lab.