EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: enhanced seq record
From: Benjamin Franksen <[email protected]>
To: [email protected], [email protected]
Date: Sat, 28 Jan 2006 00:25:46 +0100
[warning, slightly longer post]

Hello Everyone,

I am in the process of writing an enhanced version of the seq record[1] 
(named 'sequence' record to distiguish it from the old one). Current 
status is "working prototype". I send this message in order to find out 
if there are others who would like to use it and to give anyone 
opportunity to request additional features or propose changes. 
Hopefully, this record will eventually move to base (and retire the 
current seq record).

What prompted me to start this was repeated frustration about seq record 
being limited to numbers, i.e. its inability to read or write strings. 
Thus, it is impossible to use a seq record to e.g. change link fields 
in other records. Available solutions to the problem (such as using a 
sequence program, or a genSub record, or an external caput-script, or 
whatnot) are either complicated, unsafe, too heavy-weight or simply 
awkward. <aside>Similar problems exist with other standard record 
types, e.g. sel, calc, etc.</aside>

The new sequence record is able to get and put any kind of (scalar) 
value via its input and output links.

My current version has, for each 'channel' (link group):

old	new	is-good-for
--------------------------------
DLYn	DLYn	delay
DOLn	INPn    input link
LNKn	OUTn    output link
 --	FTVn    field type of VALn (menuFtype)
DOn	VALn    value to be send over OUTn

The index letter 'n' ranges from '0' to 'F' (=16). [I changed the field 
names to make their meaning a bit more obvious. Numbering starts at 0 
to match SELM semantics; SELN semantics changes accordingly.]

The most important difference is that the VALn fields have dynamic type. 
This type is recorded in (read-only) field FTVn and is (at runtime) 
determined from the coresponding OUTn link, the default being 
DBF_STRING, e.g. for uninitialized or malformed OUTn or if the target 
field is DBF_NOACCESS or otherwise write-prohibited. BTW, the FTVn 
fields are not essential; they could be removed w/o loosing anything 
important.

The way the several link groups are processed is the same as for the seq 
record, i.e. during processing, the INPn input links retrieve the value 
according to FTVn, place it in VALn, and then write the value via OUTn; 
delays are cumulative for all selected link groups.

A disadvantage in comparison to the old (=current) seq record is a 
somewhat higher memory consumption, due to all VALn fields being 
MAX_STRING_SIZE (=40) bytes large, instead of sizeof(double) (=8). I 
see the following ways to take care of this problem:

(1) Ignore it. We are talking about another 500 bytes per record. You'd 
need hundreds or thousands of them on your IOC to make a noticeable 
difference even on ancient 68k boards.

(2) No VALn fields. They are of limited use, anyway. Mostly they are 
needed in order to provide constant input, i.e. if the INPn link is 
empty. It is true that input links can hold a constant value, too, but 
unfortunately not a string value, only a numeric one, because when 
writing to a link field, anything that doesn't look like a number is 
interpreted as a PV. <aside tone=rant>This has been driving me nuts 
ever since I learned about epics; it could have been so easily avoided 
by a trivial change of the link definition syntax.</aside>

(3) Dynamically allocate storage for VALn. I am halfway convinced to add 
this, however, I tend to an "allocate on demand but never free" policy, 
the assumption being that a field that has once been used is likely to 
be used later again.

(4) Dynamically change the field type of INPn. We could have 
type-of-INPn (TOIn) fields to chose between 'link' and 'constant'. This 
can be done using cvt_dbaddr in the same way as for the VALn fields. 
Thus, before writing some some string value to INPn, you'd set TOIn to 
'constant'. Disadvantage: desn't work when initially loading the 
database. See rant above under (2).

This is (among else) a request for advice/opinions on which of the four 
is deemed best. Other comments/ideas are welcome, too, of course.

[1] http://www.aps.anl.gov/epics/wiki/index.php/RRM_3-13_Sequence

Ben

Replies:
Re: enhanced seq record Tim Mooney
Re: enhanced seq record Luedeke Andreas
Re: enhanced seq record Brian McAllister

Navigate by Date:
Prev: RE: C++ compiler versions Jeff Hill
Next: RE: enhanced seq record Chestnut, Ronald P.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: C++ compiler versions Jeff Hill
Next: Re: enhanced seq record Tim Mooney
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·