3.14.12 caget without -c always requests maximum element count
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
EPICS Base |
Fix Released
|
Undecided
|
Andrew Johnson | ||
3.14 |
Fix Released
|
High
|
Andrew Johnson |
Bug Description
From Mark Rivers
I am trying to read a large array from a VME IOC using caget. The array is 500000 elements, 32-bit integers. EPICS_CA_
The IOC is running 3.14.12.1.
Here is the output of caget from a Linux client with EPICS 3.14.10, 3.14.11, and 3.14.12.1 when requesting 499000 elements, (1000 fewer than maximum) which should fit in EPICS_CA_
3.14.10:
corvette:
Tue Jun 7 17:03:37 CDT 2011
Tue Jun 7 17:03:38 CDT 2011
3.14.11:
corvette:
Tue Jun 7 17:03:55 CDT 2011
Tue Jun 7 17:03:56 CDT 2011
3.14.12.1:
corvette:
Tue Jun 7 17:04:07 CDT 2011
CA.Client.
Warning: "The requested data transfer is greater than available memory or EPICS_CA_
Context: "op=0, channel=
Source File: ../getCopy.cpp line 92
Current Time: Tue Jun 07 2011 17:04:07.629564143
.......
So on 3.14.10 and 3.14.11 it works as expected, caget is requesting fewer than the number of bytes that EPICS_CA_
The same error happens on 3.14.12.1 even if I try to only read 100 elements:
corvette:
CA.Client.
Warning: "The requested data transfer is greater than available memory or EPICS_CA_
Context: "op=0, channel=
Source File: ../getCopy.cpp line 92
Current Time: Tue Jun 07 2011 17:24:56.617989921
.......
I then increased EPICS_CA_
corvette:
Tue Jun 7 17:16:25 CDT 2011
Tue Jun 7 17:16:26 CDT 2011
corvette:
Tue Jun 7 17:16:44 CDT 2011
Tue Jun 7 17:16:45 CDT 2011
corvette:
Tue Jun 7 17:16:55 CDT 2011
Tue Jun 7 17:16:56 CDT 2011
So it looks like there is something wrong with 3.14.12.1 when EPICS_CA_
Related branches
Changed in epics-base: | |
assignee: | nobody → Ralph Lange (ralph-lange) |
summary: |
- 3.14.12 ca fetches always maximum element count + 3.14.12 caget without -c always requests maximum element count |
no longer affects: | epics-base/3.15 |
Changed in epics-base: | |
status: | Fix Committed → Fix Released |
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