Re: Using subArray

[Carl Lionberger <CALionberger@lbl.gov>]

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