Experimental Physics and
Industrial Control System

"Lawrence T. Hoff" <[email protected]> · Mon, 20 Dec 2004 12:20:53 -0500

Andrew Johnson wrote:

How about creating your own modified version of the SEL record with
slight modification to the code: In the calculation for SELECT_HIGH
(and probably for SELECT_LOW as well for symmetry) have it set
psel->seln=i as well as recording the highest value. Then you can
read the SELN field to find the index you want.
We probably ought to make this change in the Base version of the
selRecord as it seems like a common kind of issue, but I don't know
how many existing databases it might break so I'd welcome any feedback
positive or negative on the suggestion.

 Technically, that seems like an ideal solution to my particular
application. It is simple

to implement, is logically consistent with the SEL record behavior,
completely solves

my problem (e.g. I don't need a monitor on SELN), and is unlikely to be
incompatible

with existing use.
 Sociology is another issue..... It seems unlikely to me that your
suggestion would

break anything but the most contrived and non-mainstream application.
However,

the larger the user base, the more likely contrived and non-mainstream
applications

become!
 Once can certainly avoid breaking legacy application by introducing
yet more

mode selections (e.g. "High Signal Index"), while leaving the behavior
of existing

mode selections unchanged. However, that could lead to unecessary, and
potentially

confusing "mode creep".
 I suppose big, bold warnings in EPICS release notes should be
sufficient to

warn users of new record functionality that comes with new versions of
EPICS,

especially if they come with guidance on how to work around new
functionality

which "breaks" existing applications. I do wonder if anyone ever really
reads

release notes before they commit to an upgrade, though........
 I could make my own record for my own application, but that seems a
rather

heavy-handed approach, especially since I can use a group of CALC records

or a single SUBROUTINE record, and not incur the maintenance burden of

a new record (which has 99% functionality overlap with the SEL record).
 I look forward to watching the "social side" of how this issue plays
out.

Meanwhile, I find that by pairing each of my "goodness" ao records with a

calc record, and using two SEL records, I can implement my application

in a understandable (IMHO) way, so the issue has become moot. If your

proposed functionality becomes available, all those CALC records and one

SEL record would become unecessary.
-- Larry

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System