Re: Status return from EPICS device support

[Andrew Johnson <anj@aps.anl.gov>]

Jeff Hill wrote:
> 
> We could avoid this overhead by adding a new pseudo field name to
> all records which does not exist in the recod but is instead fetched
> through a new entry at the end of the record support entry table.
> This RSET entry might then call a new entry at the end of the device
> support entry table.

Adding entries to the device support table is IMHO impractical now -
different record types and device support types have already extended it
for their own purposes.  There is no central declaration of what a struct
DSET looks like - at least not one that is used universally.  Most device
support layers declare the struct DSET contents for themselves, which
means the compiler is unable to check whether you've remembered to change
it.  We could add new routines to the DSXT Device Support eXtension Table
that I propose for implementing link support, but I suspect that Fritz
doesn't want to wait until R3.15 is released.

The simplest approach to solve his problem would probably be to add
another field to dbCommon (sound of Marty throwing up his hands in
horror), which is a long status value for device support use. There's
nothing stopping Fritz doing this in his local installation, although I
suspect Marty might not accept it within the standard Base release without
*lots* of persuasion.

I have created AI or MBBI support in the past to provide this kind of
readback status for the whole bus - each bus interface has a separate
record which indicates whether it's working properly or not.  However this
would be impractical if a separate status value is associated with an
individual I/O point.

The only other approach that I can think of is to map the 1553 status
values into one of the choices available for the STAT field, but this may
not provide enough fine control for the particular use that you need for
this status.

- Andrew
-- 
Complexity comes for free, Simplicity you have to work for.