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: "Redman, Russell O." <[email protected]>
To: EPICS tech-talk <[email protected]>
Cc: Benjamin Franksen <[email protected]>, "'Andrew Johnson'" <[email protected]>, Marty Kraimer <[email protected]>
Date: Tue, 14 Aug 2001 13:20:57 -0700
Dear Benjamin,

Have your read Andrew's proposal for link support (see
http://www.aps.anl.gov/asd/people/anj/slac99/lnkSup.html)?  This would
provide a more flexible approach to device support and I think would answer
all our needs.  Especially, Raw Soft could be configured with values for
RAWL and RAWF, which combined with EGUL and EGUF give complete control over
EOFF and ESLO.  He also discusses the use of subroutines as special purpose
links.  It actually sounds a lot like what you are proposing, but ties the
conversion to a modified version of device support rather than to record
support (where it might clash with device support).

Andrew's last message implies that link support will be included in a
release of EPICS in the not-too-distant future:
> 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 went looking for any discussion of link support in the R3.14.alpha2
release notes and IOC Application Developer's Guide, but did not find it.
Could Andrew or Marty comment on the state of this proposal?

I feel some urgency in the answer to this question.  My project has to be
essentially completed in the next year, and a great deal of the database
will be written in the next few months.  I have been waiting hopefully for
the last year for R3.14 to be officially released, and it has not yet
escaped from alpha status.  Link support seems likely to be even more
delayed.

Cheers,
Russell O. Redman

-----Original Message-----
From: Andrew Johnson [mailto:[email protected]]
Sent: Tuesday, August 14, 2001 12:00 PM
To: Marty Kraimer
Cc: Benjamin Franksen; EPICS tech-talk
Subject: Re: RAWF, RAWL


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 Andrew Johnson

Navigate by Date:
Prev: Re: RAWF, RAWL Andrew Johnson
Next: Re: RAWF, RAWL Andrew Johnson
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: YAPFAC (yet another proposal for analog conversion) Benjamin Franksen
Next: Re: RAWF, RAWL Andrew Johnson
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 ·