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
<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: 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
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|