On Freitag, 22. Oktober 2010, Ralph Lange wrote:
> On 21.10.2010 21:25, Ben Franksen wrote:
> > Yes. I use this record type heavily for all sorts of conversion
> > tasks. It is one of the most-reused pieces of code I have ever
> > written.
> >
> > The cvt record is a lot more flexible than ao. As Ralph indicated,
> > it is not restricted to functions of one input variable, but can
> > also read and interpolate two-dimensional tables, i.e. calculate
> > the output from from two independent inputs. Furthermore, it can
> > load / reload tables at runtime. The actual loading of the table is
> > done asynchronously and proceeds in parallel to the conversion,
> > i.e. conversion continues to run while the table is loaded in the
> > background. Only after the table has successfully been loaded is it
> > swapped in for the old one. This means you can correct or adjust
> > tables in a running system w/o having to stop the feedforward.
>
> Question to core:
>
> As we have seen, the conversion problem occurs at many sites, and
> everyone wrote their own way out by creating a new record type.
> I think it would be safe to say that this type of conversion is an
> often-needed functionality that the EPICS core record set is missing.
>
> Should we include one of the solutions - this record or the stuff
> from asyn, whatever is more generic and appropriate - as part of
> base?
I am not sure this is a good idea. I like it that the cvt record has an
independent release schedule instead of being tied to base. Not long
ago the trend was to unbundle stuff from base and IMO this has been the
right direction. I would rather unbundle the other record types, too,
than add more record types to base.
The problem ("everyone wrote their own way out") is a general one in the
EPICS community. There are many good solutions out there but some of
them are missing visibility, so they don't get used by others. There is
http://www.aps.anl.gov/epics/modules/, but it is a bit too limited IMO:
(1) You cannot search.
(2) The description is too short.
(3) You cannot directly download.
To perform an effective full-text search (1) we need more data, e.g. a
longer description (2). The last point (3) is less important, the main
reason I listed it here is that sometimes modules vanish (because
facilities are subject to internal politics, web servers migrate and
stuff that is no longer supported gets dropped, etc). If the tar balls
were on the EPICS home page, it would guarantee long-term availability.
Cheers
Ben
--
"Never confuse what is natural with what is habitual."
-- attributed to Mahatma Gandhi
- References:
- Re: Lookup table problem Ralph Lange
- Navigate by Date:
- Prev:
Re: Lookup table problem Stephen Lewis
- Next:
Re: what was the time before 1990? Andrew Johnson
- Index:
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: Lookup table problem Stephen Lewis
- Next:
Error in creating the example application xyz140406
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|