[warning, slightly longer post]
I am in the process of writing an enhanced version of the seq record
(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
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.
- Re: enhanced seq record Tim Mooney
- Re: enhanced seq record Luedeke Andreas
- Re: enhanced seq record Brian McAllister
- Navigate by Date:
RE: C++ compiler versions Jeff Hill
RE: enhanced seq record Chestnut, Ronald P.
- Navigate by Thread:
RE: C++ compiler versions Jeff Hill
Re: enhanced seq record Tim Mooney