Experimental Physics and
Industrial Control System

Eric Bjorklund <[email protected]> · Mon, 1 May 2000 13:16:56 -0600

Timo, Marty,

Sorry for the delay in responding.  I was out of the office most of last
week.

Since I didn't got a response to the my April 1996 post, we side-stepped the
problem by having our device support write routine restore NELM to its
original value after each write. And then forgot about the problem (for 4
years).  We never altered the aaoRecord code.

So, in response to my original questions:

> o Shouldn't "put_array_info" be updating the NORD field instead of the
>   NELM field? (if so, it means we should probably change the code in
>   devAaoCamac.c as well).

Yes, I believe it should.

> o What is the correct value, NELM (the capacity of the record) or NORD
>   (the number of points actually written) to return from "cvt_dbaddr"
>   and "get_array_info"?

For an output record, these routines should probably return NELM (the capacity
of the record) rather than NORD (the size of the last write).  I believe that
is how the aao record works now.

> o (and, BTW...  shouldn't SIOL be defined as an OUTLINK on an aao
>   record?)

Yes.  But that's another fix...  Speaking of which:

>On Fri, 28 Apr 2000, Marty Kraimer wrote:
>
> Here is another problem for  aai and aao.
>
> The init_record looks like
>
>     if (pass==0){
>         if(paai->nelm<=0) paai->nelm=1;
>         return(0);
>     }
>
> And then it waits for device support to allocate space for the array during
> pass
> = 1. This can lead to severe problems since storage MUST be allocated during
> pass 0. If another record has a link to the array and this record gets
> initialized before thye array record bad things will happen. If you and Eric
> decide to fix the problem I have an idea that may work. It dose mean,
>however,
> that associate device support also needs to be modified.

As I understand things now, record support needs to be the one allocating the
buffer space since the device-support record_initialization routine only
gets called during pass=1.  This particular bug has not been a problem for
us (yet), but I can see where it could be.  I'd be interested in seeing your
solution Marty.

>
>For me it is easy to modify what I have now, because it is in the
>beginnings. Could people who are using aai/aao comment on the implications
>of changing the record support code?
>
>Timo
>

We have a grand total of two (2) device support routines for the aao record,
so it would be no big deal for us to change the way it works.  I'd vote to
go for it -- particularly since the init problem could be pretty nasty.

The comments on the aaoRecord.c code indicate it is from Jefferson Lab
(the facility formerly known as CEBAF).  So I would guess that is where
the most investment in aao records resides.  Any comments from that front?

Eric Bjorklund
LANSCE-6 (Accelerator Operations and Support)
Los Alamos National Laboratory
[email protected]

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System