Kay-Uwe Kasemir wrote:
Things I had in mind:
- Add a 'maximum' or 'average' to some ai, ao, calc, subroutine, ...
record instances
> - Make a record post all/some values to a logging facility
> or circular buffer
Ok, these are the filters I was talking about - the ability to take a
posted value, apply some additional processing and export the result.
- Add a(n additional) forward link to a record
If we take Ralph's (IIRC) suggestion that the FLNK field be an array of
links, you wouldn't need this. I'm not totally convinced about that
yet, but it's one solution; another would be to just use a fanout record
which is exactly what it was designed for...
In case of the max., average, ..., I think it would be really nice
to have this as a field of the record. How else would I access
the current maximum? I'd like to access it via CA, see it in dbpr, ...
By "export the result" above, I mean make it available through CA as
another named view of the record it applies to. Thus if we provided a
general-purpose "maximum" filter you could connect it to say the value
view of your record "fred" and it would then make the running maximum of
"fred.value" available as a "fred.max" (or whatever you named your new
maximum filtered view). The maximum calculation would be performed by
the filter every time the record posts a new value to the underlying view.
The record has no knowledge of the presence of the filter, it doesn't
have to call any hook routines, and the field view doesn't have to know
anything about an extra field, since this isn't one at all. This exact
same approach can be used to implement the circular buffer logging
facility, and using views this could permit clients to specify
parameters to the view - say "give me the history data for just the last
10 seconds."
Actually, I don't use the FLNK, HIGH, SIML, ... fields in most records,
so could they all go and only be added as required?
That's a rather different requirement, the problem is how you would
connect all the little pieces together and execute them at the right
time. I'd like to find some way of making records out of smaller
objects, but I don't think we're anywhere near that yet.
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?
Absopositively. What do you suggest?
Does the above describe an acceptable alternative?
- Andrew
--
Podiabombastic: The tendency to shoot oneself in the foot.
- Replies:
- Re: Record support and user-defined fields Benjamin Franksen
- 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
- Re: Record support and user-defined fields Andrew Johnson
- Re: Record support and user-defined fields Kay-Uwe Kasemir
- Navigate by Date:
- Prev:
Re: Record support and user-defined fields Kay-Uwe Kasemir
- Next:
Re: Record support and user-defined fields Benjamin Franksen
- 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 Kay-Uwe Kasemir
- Next:
Re: Record support and user-defined fields Benjamin Franksen
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|