EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Lookup table problem
From: Ben Franksen <[email protected]>
To: [email protected]
Date: Fri, 22 Oct 2010 19:15:28 +0200
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  <20102011  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  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·