Experimental Physics and
Industrial Control System

Carl Lionberger <[email protected]> · Wed, 30 Nov 2005 10:31:17 -0800

Hi Michael,
These sorts of decisions seem like a matter of timing to me. If you
wait until the subarray is modified (if it ever is) your project will be
late, so you can't do that. If you modify it yourself but not in the
manner that ends up in base you will always have to be fixing each new
release at your installation regardless of whether or not the subarray
gets changed or at least until you resynchronize with a newer more
compatible version. While it needs to be repeatedly fixed you have to
document it in case you leave the project. (not to indicate one
shouldn't document everything anyway!) If you write device support for
records you can use without modification it might take longer now but
the job will be done.
Carl
Michael Abbott wrote:
On Wed, 30 Nov 2005, Carl Lionberger wrote:
I think the thing to do would be to separate out the soft support for
the subarray record from the rest of the record; it really is too
closely coupled now. Then whatever buffering it uses to deal with
the outside could be in the device support code which would be
tailored as needed.

Should I take this as a hint that my hack is likely to come unstuck?
In truth I'm tending back to using separate length and index controls
managing standard waveform records, but it isn't that code's turn yet...
I took care to avoid tampering with epics itself, so the only change
I've made is that my subArray init_record reassigns MALM to a much
larger value. I haven't worked that code very hard yet, as other
stuff has intervened, but at first glance it seemed to work ok.

--
Carl Lionberger
Control System Software Engineer
Berkeley National Laboratory (LBNL)
(510)486 7503

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System