Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017 
<== Date ==> <== Thread ==>

Subject: Re: labCA and EPICS_CA_MAX_ARRAY_BYTES
From: "J. Lewis Muir" <jlmuir@anl.gov>
To: EPICS Tech-Talk <tech-talk@aps.anl.gov>
Date: Fri, 28 May 2010 14:08:37 -0500
On 5/28/10 1:51 PM, Till Straumann wrote:
> All polemics aside - I do know what the current situation is and
> that there are historic and maybe technical reasons (which can
> always be overcome) for this situation.
> 
> Nevertheless, I do understand Matt's point of view. It is simply
> not very user-friendly that you have to think what the largest
> array may be you want to transfer and to have to set
> EPICS_CA_MAX_ARRAY_BYTES
> on both, the IOC and the client side, IIRC before you start either.
> 
> An IOC application designer is not necessarily aware of the
> correct size and when the client-side user finds out that
> he/she cannot transfer, learns about and sets EPICS_CA_MAX_ARRAY_BYTES
> he/she has then to go back and educate the IOC-app designer
> who then has to set the variable and eventually reboot the IOC.
> 
> If this sequence happens a few times then the annoyed
> engineer will simply set EPICS_CA_MAX_ARRAY_BYTES to
> some large number everywhere
> 
> IMHO it would be desirable to do away with EPICS_CA_MAX_ARRAY_BYTES
> and implement some better, dynamic buffer management scheme.

I too understand Matt's view.  On at least two separate occasions I've
been bitten by this and had to set EPICS_CA_MAX_ARRAY_BYTES to a larger
value to make things work.

It would be much nicer if this would just work out-of-the-box.  A
dynamic buffer management scheme as Till suggested or some other
approach would be great from my point of view.  It would be one less
thing to have to set up.  Of course, if there's no good solution, then
fine, I can work w/ it as is.  But if something reasonable could be done
to get rid of EPICS_CA_MAX_ARRAY_BYTES, that would be great.

Thanks,

Lewis

-- 
J. Lewis Muir
Software Engineer
IMCA-CAT

References:
labCA and EPICS_CA_MAX_ARRAY_BYTES John Dobbins
Re: labCA and EPICS_CA_MAX_ARRAY_BYTES Till Straumann
Re: labCA and EPICS_CA_MAX_ARRAY_BYTES emmanuel_mayssat
RE: labCA and EPICS_CA_MAX_ARRAY_BYTES Mark Rivers
Re: labCA and EPICS_CA_MAX_ARRAY_BYTES Till Straumann
Re: labCA and EPICS_CA_MAX_ARRAY_BYTES Matt Newville
Re: labCA and EPICS_CA_MAX_ARRAY_BYTES Ralph Lange
Re: labCA and EPICS_CA_MAX_ARRAY_BYTES Matt Newville
Re: labCA and EPICS_CA_MAX_ARRAY_BYTES Ralph Lange
Re: labCA and EPICS_CA_MAX_ARRAY_BYTES Till Straumann

Navigate by Date:
Prev: Re: labCA and EPICS_CA_MAX_ARRAY_BYTES Till Straumann
Next: building base on cygwin1.7 Pete R. Jemian
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017 
Navigate by Thread:
Prev: Re: labCA and EPICS_CA_MAX_ARRAY_BYTES Till Straumann
Next: iPhone port Pelaia II, Tom
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·