EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: More flexible record scanning
From: Benjamin Franksen <[email protected]>
To: [email protected]
Date: Tue, 28 Jun 2005 12:17:24 +0200
On Monday 27 June 2005 16:33, Andrew Johnson wrote:
> Benjamin Franksen wrote:
> > Only for record (sic!), because I just had a problem where this
> > would have been quite useful: In R4, each record (i.e. dbCommon)
> > should have an input link targeting the PROC field.
> >
> > Standard application: a potentially large number of records needs
> > to be scanned according to what happens at some central place.
>
> Can that requirement not be implemented already in V3 using this?
>
>      SCAN=Event
>      EVNT=<some number>
>      Use an Event record to generate that numbered soft event.
>
> If the records to be processed are spread across multiple IOCs, you
> need to have one Event record in each IOC.

I got a similar answer from Marty. To re-iterate my response:

Event scanning using raw numbers is much too fragile. It means you 
cannot load two independently developed databases on the same IOC 
without incurring the risk that both happen to use the same event 
number(s) for entirely different purposes. Such an error would not 
become apparent when loading the databases, but only later during 
runtime, possibly a lot later if the events in question occur rarely. 
Thus, the error may be quite subtle and cost you a lot of time to 
debug.

Note that the two databases may work absolutely correct when used 
separately, i.e each loaded on a dedicated IOC (a setup you would 
typically use during development).

In contrast, an input link for the PROC field never accidentally 'leaks' 
to the outside, at least if the 'scanning' record instance is part of 
the same database file.

Ben

Replies:
Re: More flexible record scanning Andrew Johnson
References:
More flexible record scanning Benjamin Franksen
Re: More flexible record scanning Andrew Johnson

Navigate by Date:
Prev: Re: dataAccess V4 Ca client propertyId questions Andrew Johnson
Next: Re: V4 design issue: Should primitive data types have well defined precisions? Ralph Lange
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: More flexible record scanning Andrew Johnson
Next: Re: More flexible record scanning Andrew Johnson
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·