EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: Re: Record support and user-defined fields
From: Andrew Johnson <[email protected]>
To: Kay-Uwe Kasemir <[email protected]>
Cc: EPICS Core Talk <[email protected]>
Date: Thu, 07 Jul 2005 13:26:07 -0500
Kay-Uwe Kasemir wrote:
I see good reasons for both adding fields to record instances
(easy to use, but limited functionality)
and having building blocks for new records
(requires more forethought but also more options).

Can I get you two to think about these requirements at a slightly higher level and describe what it is you're trying to achieve, rather than how we should actually implement it.

Here's what I think Kay is looking for: The ability on an IOC to add a filter to a value coming from a record, and to export the output of that filter. I'm not sure how you were planning to control the filter, but I guess we'd want to be able to do that somehow as well. The example you use is to add a smoothing filter, but Matthias' Channel History would I think be another suitable example. If I can suggest an alternate approach that could provide this functionality but doesn't involve "adding a field at runtime", would you accept this instead? This specific implementation idea really feels to me like adding a sail to a sports car, and I would like to leave us with more flexibility in the actual implementation by only specifying the kinds of things we need to be able to do, not how to do them.

I like Ben's idea of introducing type parameters into the DBD file, but I want to make some changes to his struct support. I'd like to distinguish between a struct (which should only contain plain data) and a class (which also has methods that have to be implemented in C++ code). It would obviously save effort if we only have to write the alarm limits checking code once as a template, which can then be instanciated for all types as needed, and this starts to break up a record into smaller modules that have a defined functionality. The parent record type code would still be responsible for connecting all of the modules together into a cohesive whole record.

I hope I can find the time to put type parameters and class stuff into my DBD document before the meeting.

- Andrew
--
Podiabombastic: The tendency to shoot oneself in the foot.

Replies:
Re: Record support and user-defined fields Kay-Uwe Kasemir
Re: Record support and user-defined fields Marty Kraimer
References:
V4 iocRecord: forward linking Ralph Lange
Re: Record support and user-defined fields Benjamin Franksen
Re: Record support and user-defined fields Kay-Uwe Kasemir
Re: Record support and user-defined fields Benjamin Franksen
Re: Record support and user-defined fields Kay-Uwe Kasemir

Navigate by Date:
Prev: Re: name resolution performance Kay-Uwe Kasemir
Next: RE: name resolution performance Jeff Hill
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Record support and user-defined fields Benjamin Franksen
Next: Re: Record support and user-defined fields Kay-Uwe Kasemir
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  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 ·