Re: Initial STAT and SEVR for soft ai and ao records

[Marty Kraimer <mrk@aps.anl.gov>]

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.
>