Experimental Physics and
Industrial Control System

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.

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.

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 ([email protected]) (630)252-5417
Beamline Controls & Data Acquisition Group
Advanced Photon Source, Argonne National Lab.

References:

Change input links run-time in a db Pedersen, UK (Ulrik)

Re: Change input links run-time in a db Luedeke Andreas

RE: Change input links run-time in a db Pedersen, UK (Ulrik)

Re: Change input links run-time in a db Tim Mooney

Re: Change input links run-time in a db Maren Purves

Navigate by Date:

Prev: RE: Change input links run-time in a db Mark Rivers

Next: RE: Change input links run-time in a db Pedersen, UK (Ulrik)

Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  <2008>  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 

Navigate by Thread:

Prev: RE: Change input links run-time in a db Pedersen, UK (Ulrik)

Next: New version of the sscan module Tim Mooney

Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  <2008>  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024