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
<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:
YAPFAC (yet another proposal for analog conversion) Benjamin Franksen
- Next:
Re: RAWF, RAWL Andrew Johnson
- Index:
1994
1995
1996
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
|