I could confirm this behavior (3.14.12 soft-IOC on linux-x86_64), 3.14.8.2 and 3.14.12 client.
There are two issues:
1)
As of 3.14.12 the 'caget' program has changed (for reasons unknown to me; it rather seems a bug).
When you ask for a number of elements less than the full array count ( -# option) and do *not*
specify the 'callback' option (-c) then the 3.14.12 version of the program fetches the native count
of elements and just limits the printed number of elements. You can work around this by using -c.
2)
There is nothing wrong with EPICS_CA_MAX_ARRAY_BYTES but you must make sure that
you can accommodate the data you ask for. By default (unless you request an explicit format),
caget asks for the native number of items in the native representation (type) in DBR_TIME_xxx
format which means that in addition to the data, time-stamp and status information also are
transferred. If you just want the pure data then you can specify a format
export EPICS_CA_MAX_ARRAY_BYTES=2000000
caget -d LONG
I could confirm this behavior (3.14.12 soft-IOC on linux-x86_64), 3.14.8.2 and 3.14.12 client.
There are two issues:
1)
As of 3.14.12 the 'caget' program has changed (for reasons unknown to me; it rather seems a bug).
When you ask for a number of elements less than the full array count ( -# option) and do *not*
specify the 'callback' option (-c) then the 3.14.12 version of the program fetches the native count
of elements and just limits the printed number of elements. You can work around this by using -c.
2) MAX_ARRAY_ BYTES but you must make sure that
There is nothing wrong with EPICS_CA_
you can accommodate the data you ask for. By default (unless you request an explicit format),
caget asks for the native number of items in the native representation (type) in DBR_TIME_xxx
format which means that in addition to the data, time-stamp and status information also are
transferred. If you just want the pure data then you can specify a format
export EPICS_CA_ MAX_ARRAY_ BYTES=2000000
caget -d LONG
HTH
-- Till