Experimental Physics and Industrial Control System
|
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
<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: Record support and user-defined fields Benjamin Franksen
- Next:
Re: Record support and user-defined fields Kay-Uwe Kasemir
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|
ANJ, 02 Feb 2012 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|