Experimental Physics and
Industrial Control System

Hi Ritesh,

In the best approximation of trying to reproduce this problem, I see
different behavior.

On 64-bit linux (fedora core 14, x86_64) with Epics Base 3.14.12.1, I
see from the command line:

  ~> export EPICS_CA_MAX_ARRAY_BYTES-65536 ; caget Py:char64k

works (Py:char64k having native_type=DBF_CHAR, element_count=65336).
In fact, I see

  ~> export EPICS_CA_MAX_ARRAY_BYTES=65528 ; caget Py:char64k

works, while

  ~> export EPICS_CA_MAX_ARRAY_BYTES=65527 ; caget Py:char64k

gives the message that EPICS_CA_MAX_ARRAY_BYTES is too small.  I get
the same results on 32-bit linux and 32-bit windows.

With Python (testing with Python 3.1 and 2.6), I see similar behavior,
though oddly EPICS_CA_MAX_ARRAY_BYTES works down to 65313 (on 64-bit
linux, 32-bit linux, and 32-bit windows), perhaps due to some details
of memory allocation that should not be relied upon.

I'm sure that working below or right at this threshold is not
recommended, and that setting EPICS_CA_MAX_ARRAY_BYTES somewhat higher
than you think you really need is the safer option.  On the client end
(especially a 64 bit linux machine), I would think that setting
EPICS_CA_MAX_ARRAY_BYTES to twice what you think you need is
reasonable.

It does seem that you're working hard at pushing on these and other
limits of Channel Access libraries (especially python) and reporting
problems without giving very full reports of what does work.  For
example, what value of EPICS_CA_MAX_ARRAY_BYTES does work for you?
Did you test the basic command line caget as well as your python
script -- this would help very much in isolating the issue.

Finally, it seems you're putting a lot of effort into testing the CA
python libraries. Would you be willing to work on these libraries?

Cheers,

--Matt