EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: Re: Calling an iocsh "sub-script"
From: Stephen Lewis <[email protected]>
To: "J. Lewis Muir" <[email protected]>
Cc: EPICS Tech-Talk <[email protected]>
Date: Thu, 14 Oct 2010 06:48:16 -0700
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  <20102011  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  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 14 Oct 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·