EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: Re: Status return from EPICS device support
From: Andrew Johnson <[email protected]>
To: Jeff Hill <[email protected]>
Cc: [email protected], EPICS-tech-talk <[email protected]>
Date: Thu, 25 May 2000 13:41:29 -0500
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.


Replies:
RE: Status return from EPICS device support Jeff Hill
Re: Status return from EPICS device support Steve Lewis
References:
RE: Status return from EPICS device support Jeff Hill

Navigate by Date:
Prev: RE: Status return from EPICS device support Jeff Hill
Next: RE: Status return from EPICS device support Jeff Hill
Index: 1994  1995  1996  1997  1998  1999  <20002001  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: Status return from EPICS device support Jeff Hill
Next: RE: Status return from EPICS device support Jeff Hill
Index: 1994  1995  1996  1997  1998  1999  <20002001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·