Experimental Physics and
Industrial Control System

"Mark Rivers" <[email protected]> · Fri, 27 Jan 2006 18:17:44 -0600

Hi Ron,

Are you aware of the "sseq" record in synApps at the APS?

Here is the beginning of the documentation for it:
"The String Sequence record is similar to the Sequence record, and has
all of its capabilities, but it also can link from either string or
double fields to either string or double fields. The record is used to
trigger the processing of up to ten other records and send values to
those records. It is similar to the fanout record, except that it will
fetch an input value and write an output value instead of simply
processing a collection of forward links. It can also specify one of
several selection algorithms that determine which values to write. It
has no associated device support. Its fields fall into the following
categories: "

Mark

> -----Original Message-----
> From: Benjamin Franksen [mailto:[email protected]] 
> Sent: Friday, January 27, 2006 5:26 PM
> To: [email protected]; [email protected]
> 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
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System