EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  <19951996  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  Index 1994  <19951996  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 
<== Date ==> <== Thread ==>

Subject: output record initialization
From: [email protected] (William Lupton)
To: [email protected]
Date: Thu, 31 Aug 95 09:47:30 HST
Dear all,

  How do you set an initial value for an output record (ao, bo, mbbo, longout,
stringout etc)?

  The current behavior of init_record() is as follows (I've taken this from
the ao record but the others all seem very similar):

1. if DOL is a constant, it is copied to VAL and UDF is set FALSE
2. if device support supplies an init_record() routine, it is called
3. if so and status 2 is returned, no conversion is performed
4. if so and status 0 is returned, normal conversion from RVAL is performed

  The result is that a DOL initial value is honored only if:

1. there is no device support init_record() routine, or
2. the device support init_record() routine returns status 2

Also, if a device support record_init() routine is going to return status 0 it
should always have set RVAL to something sensible.

  The issue arises: what if the database designer _wants_ to force an initial
value for a record? Currently he can't be sure that this is possible, because
it's up to device support. Should there be a means of doing this? If so,
presumably there needs to be a new "force init" field (FINI?) which says that
the DOL constant value is to be used regardless. What if you want to give a
record an initial value but want to retain the option of running it in closed
loop mode? Perhaps a field other than DOL should be used for the initial value
(IVAL? --- already used for this purpose in the steppermotor record). For
upwards compatibility, IVAL would only be used if FINI is YES.

  I would propose (and I expect that this is what is happening already in most
if not all cases) that the device support init_record() should _always_ read
RVAL from the hardware and return 0 if it is capable of doing so. If it is not,
then I think that usually the best behavior would be for device support to set
RVAL to a suitable default and still return 0. With the above FINI / IVAL
scheme, the application designer can still provide his own default to override
that provided by device support.

  Any comments?

  William


Navigate by Date:
Prev: Q: NI-1014 GPIB board with Force CPU40. Noboru Yamamoto
Next: Re: output record initialization Gordon Uchenick
Index: 1994  <19951996  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: Q: NI-1014 GPIB board with Force CPU40. Noboru Yamamoto
Next: Re: output record initialization Gordon Uchenick
Index: 1994  <19951996  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 
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 ·