A simple if brute-force technique used at SLAC: add 'iocshCmd(dbl)>some-NFS-file-with-ioc-name' so each IOC dumps a complete PV list. The crawler can parse this quite easily.
On 13 Oct 2010, at 10:57 AM, J. Lewis Muir wrote:
> On 10/13/10 11:45 AM, Ben Franksen wrote:
>> On Mittwoch, 13. Oktober 2010, Josh Stein wrote:
>>> I would like to point out one warning with these embedded scripts -
>>> there is a very real possibility of breaking some higher level tools
>>> which rely on 'crawling' the startup command files for information.
>>> This very issue has just cropped up here at APS when the st.cmd
>>> structure of a number of our production IOCs was cleaned up during a
>>> recent 3.14 upgrade.
>>>
>>> In essence, some of our crawlers were unable to parse relevant tags
>>> since they failed to show up in the st.cmd file itself as those tags
>>> were moved to one or more of the 'sub-scripts'.
>>>
>>> For now, the crawlers at APS are being re-written to follow the
>>> indirection. This is yet another example of how fragile the system
>>> structure can grow over time; the hooks into various parts actually
>>> increase the risk of things breaking as time progresses.
>>
>> Yup. Reverse engineering installed files is a simple and clever solution
>> to the practical problem of finding out what is actually installed. But
>> *of course* it is liable to break whenever the *structure* of the
>> installed stuff changes.
>>
>> The obvious solution to the dilemma is to create a central service that
>> serves as source to both the installed files *and* the big picture
>> (e.g. Irmis) and presumably other stuff like alarm handlers etc. But
>> how can we design something like that while still retaining the easy
>> editability (and the ability to use version control systems) that we
>> have with plain text files? This is the million dollar question we have
>> been discussing at BESSY ever since it became clear that a growing
>> number of Oracle database tables (with a specific set of tables for
>> each kind of device/application) is *not* an easily editable and
>> maintainable solution in the long run.
>
> Hi, Ben.
>
> I would agree that putting everything in a relational database is not an
> easily editable solution.
>
> Of course, the problems people are trying to solve may vary widely, so
> Irmis or similar may be a good solution for some situations.
>
> I agree that having one source for all the information is good. If one
> lets the EPICS IOC shell .cmd files be the source, and if the goal is to
> determine what EPICS PVs are defined after loading the .cmd files, then
> I think a possible solution would be some kind of dry-run mode where one
> could load .cmd files and the EPICS internals that construct records
> would write the name and type (and any other info considered to be
> important) of each record they would create to a file, but not actually
> create the record. The record name and type pair would allow
> determining every possible PV name. I'm sure plenty of people have
> thought of this problem in general, so maybe there's a better way. But
> the idea here is to not have some separate program trying to figure this
> stuff out; instead make the EPICS internals capable of reporting it
> right when they would have actually created the record.
>
> Lewis
- References:
- Calling an iocsh "sub-script" Angus Gratton
- RE: Calling an iocsh "sub-script" Mark Rivers
- Re: Calling an iocsh "sub-script" Josh Stein
- Re: Calling an iocsh "sub-script" Ben Franksen
- Re: Calling an iocsh "sub-script" J. Lewis Muir
- Navigate by Date:
- Prev:
Re: Calling an iocsh "sub-script" Ben Franksen
- Next:
Re: Calling an iocsh "sub-script" J. Lewis Muir
- 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: Calling an iocsh "sub-script" J. Lewis Muir
- Next:
Re: Calling an iocsh "sub-script" J. Lewis Muir
- 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
|