EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  2007  2008  2009  2010  2011  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  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Initial STAT and SEVR for soft ai and ao records
From: Benjamin Franksen <[email protected]>
To: [email protected]
Date: Wed, 16 Feb 2005 14:36:28 +0100
On Wednesday 02 February 2005 17:56, Bernhard Kuner wrote:
> >Saying PINI=Yes is not "saying this record is processed", it
> > actually processes the record.  That can have major side-effects,
> > if it has PP or CP links to other records.
>
> Yes, this "side-effects"  is what I'd expect. The record will be
> processed once and all records that are linked to it / monitore its
> value will be updated with the value from the DOL field. That is why
> I design an EPICS database. Where is the problem?

The problem is that one may want to achieve certain effects (*) of 
processing (e.g. resetting the record's stat/sevr), while avoiding 
certain other effects (e.g. writing to HW). This is only possible with 
disproportionate effort (e.g. switch record to simulation mode, 
process, switch to normal mode; costing at least one additional seq 
record). Such effort not only obscures the database design by littering 
it with "helper" records, it also wastes resources.

It would help to have a record field (RESET?), similar to the PROC 
field, with the defining property that writing to it causes 
re-calculating alarm status/severity, using the current field values, 
without performing any I/O (link-wise or via device support) other than 
posting the appropriate events.

The nice & clean solution would be to make this a standard record (i.e. 
dbCommon) field, and to add a corresponding method to record support 
entry table, so that this field can be handled by the core. Until then, 
each record type must handle the new field through its "special" 
method.

On a more general note, it has been observed by many people that record 
processing is currently overwraught with too many effects, interacting 
in a too complex manner, which is furthermore slightly different 
between record types. All this makes reasoning about an EPICS database 
a daunting task, up to the point where it is nearly impossible to 
design a non-trivial database without continual (unit-)testing to 
verify that what one thinks should work is actually working in 
practice. (Because quite often, and for mostly obscure reasons, it 
doesn't.) This is especially true for people who are not (yet) 
intimately familiar with each of the standard record's own 
peculiarities.

IMHO it should be a top priority for future EPICS releases to redesign 
record processing in general, and standard record types in particular, 
such that the effects of processing are more streamlined and 
predictable. It would help a lot, if common (record support) code could 
(& would) be factored out into libraries(**); and if the protocol for 
record processing could be somewhat more formalized and maybe even 
partially enforced by the core libraries.

Ben

(*) The term "side-effect" is somewhat inappropriate here, since 
processing happens only for its effects (it doesn't return any value).
(**) ...which I readily admit is difficult to do in C due to its lack of 
polymorphism. Heresy: Maybe using C++ wouldn't be such a bad idea, 
after all.

Replies:
Re: Initial STAT and SEVR for soft ai and ao records Marty Kraimer
References:
RE: Initial STAT and SEVR for soft ai and ao records Mark Rivers
Re: Initial STAT and SEVR for soft ai and ao records Bernhard Kuner

Navigate by Date:
Prev: SSCAN and EDM Iztok Krapec
Next: Re: SSCAN and EDM Ned Arnold
Index: 1994  1995  1996  1997  1998  1999  2000  2001  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: Initial STAT and SEVR for soft ai and ao records Bernhard Kuner
Next: Re: Initial STAT and SEVR for soft ai and ao records Marty Kraimer
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·