Experimental Physics and
| |||||||||||||||||
|
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,
| ||||||||||||||||
ANJ, 02 Sep 2010 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing · |