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: Record support and user-defined fields
From: Benjamin Franksen <[email protected]>
To: [email protected]
Date: Thu, 30 Jun 2005 13:35:11 +0200
On Wednesday 29 June 2005 18:13, Kay-Uwe Kasemir wrote:
> On Jun 29, 2005, at 07:34, Ralph Lange wrote:
> > Suggestion:
> > For V4, make FLNK an array of links with a default size of zero.
>
> The user-defined field would also allow for no default FLNKs at all,
> then the user adds as many as needed.

I don't yet see how we specify when 'user-defined fields' get processed. 
(I take it, 'user-defined' here means 'per-record-instance-defined').

FLNK is deceptive as an example, because FLNK is always processed after 
everything else. In general, though, processing of additional fields 
would have to insert itself somewhere in between the other processing 
steps. But where, exactly?

I thought a lot about this question and had long discussions with Ralph 
about it. The problem is this: do we want to split record processing 
into a predefined fixed number of stages (get inputs, ..., write 
outputs, update alarm status, post monitors, process forward links)? I 
think we don't want to do that. It would limit the freedom for 
designers of new record types too much. But if we don't, how can a new 
field specify what the record is supposed to do with it and at which 
stage during processing?

Thus, I argue for abandoning the idea to have per-instance defined 
fields. Instead, let us go the other way around and do what I have been 
preaching ever since the start of the V4 debate: streamline the process 
of creating a new record type, right up to the point where, instead of 
creating ad-hoc fields, you would rather create a new record type.

This is possible only if we can assemble record support from existing 
pieces (dbd structs and their support modules) in a straight-forward 
manner. The typical process routine would be a sequence of calls to 
routines (from sub-structure supports), parameterized with the actual 
relevant fields of the record, which interact with the sub-structure in 
question. Sub-structures can (and must) have no knowledge of each other 
or their surrounding context (record type). The only instance that 
knows all fields is and remains the record support and therefore has 
the ultimate responsibility for what happens during processing.

Ben

PS: It may be necessary to templatize some of the routines of general 
purpose struct support modules. For instance, a general purpose 
alarmLimit module (struct + support routines) may be parameterized over 
the number type. Same for a general purpose calc module or smoothing 
module. A linear conversion module may be parameterized over the type 
of the raw value and the type of the engineering units value. However, 
we could also provide many specialized versions, like displayLimitF64, 
in the dbd and use templates only internally for the implementation of 
the support.
PPS: We should also generate independent DA implementations for structs. 
These can then be built upon in the (generated) DA implementation for a 
record type that uses such a struct. 

References:
V4 iocRecord: forward linking Ralph Lange
Re: V4 iocRecord: forward linking Kay-Uwe Kasemir

Navigate by Date:
Prev: Re: views Andrew Johnson
Next: Re: dataAccess V4 primitive types Ralph Lange
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: V4 iocRecord: forward linking Kay-Uwe Kasemir
Next: Re: Record support and user-defined fields Benjamin Franksen
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 ·