EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  <20012002  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  2000  <20012002  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: RAWF, RAWL
From: Andrew Johnson <[email protected]>
To: Marty Kraimer <[email protected]>
Cc: Benjamin Franksen <[email protected]>, EPICS tech-talk <[email protected]>
Date: Tue, 14 Aug 2001 14:00:27 -0500
Marty Kraimer wrote:
> 
> Benjamin Franksen wrote:
> >
> > Does this mean that ESLO and EOFF will be made configurable?
> 
> I will add promptgroup(GUI_CONVERT) to both.
> Question. What should special be?
> It is currently defined as special(SPC_NOMOD). The question becomes. Should this
> field be dynamically configurable. If we remove special(SPC_NOMOD) should we
> define asl(ASL0)?

Acording to the source for aiRecord.c, EOFF gets set to the value of EGUL
at init time and every time a special(SPC_LINCONV) field is changed
(before calling the dset->special_linconv() routine which may change it
again), so the above makes no sense for EOFF.  The ESLO field is only set
by device support, but if this field is made configurable then designers
will set it when they don't need to, and then be surprised when their
value is overwritten by any hardware device support at iocInit or when any
special(SPC_LINCONV) field is modified.  This modification is not posted
as a CA monitor, and this could cause confusion if we make ESLO
modifyable.

Would we plan to undo this promptgroup() once link support makes it
possible to specify RAWF,RAWL in the raw soft link address?  It's much
easier to loosen restrictions (this proposal) than it is to tighten them
again (undo this change when RAWF,RAWL can be specified in the raw soft
link address).

I understand that raw soft ai/ao support is not useful for linear
conversions right now precisely because of this, but I'm not sure that
this is the best time to change that, and I wonder how urgently we need to
fix that.  Would it be better to suffer the slight pain now (of not using
raw soft ai/ao to do linear conversions) than to allow it but give us
problems later when raw soft is more widely used?  I'm not trying to stop
useful changes, but I think this still opens up future difficulties
without gaining us very much immediately.

I'd appreciate some indication if anyone thinks I'm being too cautious and
obstructive about this.

- Andrew
-- 
The world is such a cheerful place when viewed from upside-down
It makes a rise of every fall, a smile of every frown


Replies:
Re: RAWF, RAWL Benjamin Franksen
References:
RE: RAWF, RAWL Redman, Russell O.
Re: RAWF, RAWL Marty Kraimer
Re: RAWF, RAWL Benjamin Franksen
Re: RAWF, RAWL Marty Kraimer

Navigate by Date:
Prev: YAPFAC (yet another proposal for analog conversion) Benjamin Franksen
Next: [Fwd: vxWorks, other ops] Rolf Keitel
Index: 1994  1995  1996  1997  1998  1999  2000  <20012002  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: RAWF, RAWL Marty Kraimer
Next: Re: RAWF, RAWL Benjamin Franksen
Index: 1994  1995  1996  1997  1998  1999  2000  <20012002  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 ·