EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  <20002001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  <20002001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: aao record behaviour
From: Korhonen Timo <[email protected]>
To: Eric Bjorklund <[email protected]>
Cc: Marty Kraimer <[email protected]>, [email protected]
Date: Wed, 3 May 2000 16:30:09 +0200 (MEST)
Eric,

thank you for your reply and sorry for my late response.

On Mon, 1 May 2000, Eric Bjorklund wrote:

> 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.

I thought so, too. But looking at the waveform record, the get_array_info
returns NORD and cvt_dbaddr returns NELM (in a dbAddr struct). 

The Application Developers guide says for get_array_info: "This routine
returns the current number of elements and the offset of the first value
of the array." For cvt_dbaddr: "This routine can change any combination of 
the dbAddr fields...". What should be returned in the dbAddr->no_elements 
is not specified, but to me it looks like it should be NELM.

What should the correct behaviour be?

> 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.

Me too!

> 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.

I would prefer that, too. I have one device support that I started
writing last week.

> 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?

I would also be interested...


best regards,
		Timo


Timo Korhonen  PSI (Paul Scherrer Institut), SLS 
               CH-5232 Villigen PSI 
               tel + 41- 56 3103262  fax + 41 - 56 310 3151 
e-mail:	       [email protected]



Replies:
Re: aao record behaviour Marty Kraimer
References:
Re: aao record behaviour Eric Bjorklund

Navigate by Date:
Prev: Tcl/Tk and JAVA Channel Access Extention Leonard J. Reder
Next: Re: aao record behaviour Marty Kraimer
Index: 1994  1995  1996  1997  1998  1999  <20002001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: aao record behaviour Eric Bjorklund
Next: Re: aao record behaviour Marty Kraimer
Index: 1994  1995  1996  1997  1998  1999  <20002001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·