RE: enhanced seq record

["Chestnut, Ronald P." <ronc@slac.stanford.edu>]

Ben,

If you do change the seq record (or make a new one), can you please change the behaviour for a "0" delay? Now a new thread is started for each (DOL/LNK) pair. If the delay is zero, can you "just do it" in the same thread? We found that for some big "explosions" (nested SEQs) the task switching dominates the processing time.

Ron Chestnut 

-----Original Message-----
From: Benjamin Franksen [mailto:benjamin.franksen@bessy.de] 
Sent: Friday, January 27, 2006 3:26 PM
To: tech-talk@aps.anl.gov; core-talk@aps.anl.gov
Subject: enhanced seq record

[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