EPICS Controls 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  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: labCA and EPICS_CA_MAX_ARRAY_BYTES
From: Till Straumann <[email protected]>
To: [email protected]
Date: Fri, 28 May 2010 13:51:39 -0500
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.

-- Till


On 05/28/2010 09:21 AM, Ralph Lange wrote:
Hi Matt,

as Andrew covered the technical aspects and pointed out solutions, I just want to clarify:

In your original mail, you sounded as you were assuming that the environment variable EPICS_CA_MAX_ARRAY_BYTES was introduced with the intention of limiting the size of arrays that CA is able to handle.

My statement was: No, it was the other way round. The limitation had been there from the beginning. The environment variable was introduced with the intention to overcome this limitation and allow CA to handle larger arrays.

Sorry for being not clear enough in the first place.

Cheers,
Ralph


On Thu 27 May 2010 21:25:01 Matt Newville wrote:
Hi Ralph,

Thanks for the reply.

On Wed, May 26, 2010 at 11:27 AM, Ralph Lange <[email protected]> wrote:
Hi Matt,

nope, it's the other way round:

Maybe I'm still not understanding completely because I don't see much difference between your explanation and what I said,

[...]


Replies:
Re: labCA and EPICS_CA_MAX_ARRAY_BYTES J. Lewis Muir
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

Navigate by Date:
Prev: Fall Epics Meeting location? Jane Richards
Next: Re: labCA and EPICS_CA_MAX_ARRAY_BYTES J. Lewis Muir
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: labCA and EPICS_CA_MAX_ARRAY_BYTES Ralph Lange
Next: Re: labCA and EPICS_CA_MAX_ARRAY_BYTES J. Lewis Muir
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·