Experimental Physics and
Industrial Control System

Andrew,

Thanks for you quick response. In my opinoin, if we support variable-sized arrays, there is no need to specify the EPICS_CA_MAX_ARRAY_BYTES. So we can achieve array allocation on demand. This is just my suggestion :)

Thanks,

Alex

Hi Alex,

Your subject line is slightly misleading, I don't think you're actually asking
about support for variable-sized arrays but about the maximum size of an
array that can be transferred over Channel Access.

On Monday 19 January 2009 04:01:46 [email protected] wrote:
>
> Currently, if we dealing with array, its max length is determined at
> "compile-time" as specified by environment variable
> EPICS_CA_MAX_ARRAY_BYTES, this means we can't change the max array length
> when a CA client is built. If this client connects an IOC supports larger
> size of arrays, we need to rebuild the client. So do we have any plan to
> support non-fixed size array?

You are incorrect about this being a compile-time only setting.  A default
value for the maximum length is compiled into the libCom library, but this
can be overridden at runtime by setting the environment variable before you
initialize the CA library — I'm not sure if Win32 supports putenv() but if
not it will have an equivalent that you can use instead.  Once CA has been
initialized though, changing the value will not affect the maximum array size
that can be transferred.

The maximum size that can be used for a particular client/server combination
is calculated as the smaller of the two settings on the client and server, so
an IOC that may not have much memory can limit how much space it has to
allocate for buffering data for clients.  Here at the APS we make the limit
fairly large on our client workstations, and allow the IOCs to control how
big it really gets.

HTH,

- Andrew
--
The best FOSS code is written to be read by other humans -- Harold Welte