Experimental Physics and
Industrial Control System

Marty Kraimer <[email protected]> · Wed, 16 Feb 2005 13:42:59 -0600

I am only answering the problem of using PINI to prevent STAT=UDF and
SEVR=INVALID.

If all that is desired to to make the record not be in alarm after
initialization then just set
   field(SEVR,"NO_ALARM")
   field(STAT,"NO_ALARM")
   field(UDF,"0")
In the record instance definition.
For example

record(ao,"junk")
{
   field(SEVR,"NO_ALARM")
   field(STAT,"NO_ALARM")
   field(UDF,"0")
}

With regards to
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.

I agree.
Marty Kraimer
Benjamin Franksen wrote:
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.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System