| 2002 2003 2004 2005 2006 2007 2008 2009 <2010> 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 | Index | 2002 2003 2004 2005 2006 2007 2008 2009 <2010> 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: Lookup table problem |
| From: | Ralph Lange <[email protected]> |
| To: | EPICS Core Talk <[email protected]> |
| Date: | Fri, 22 Oct 2010 09:42:08 -0400 |
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?
~Ralph