Hi Jeff, Xiaoqiang, Ritesh,
I was looking at Ritesh's message about array sizes and string arrays.
For what it's worth, I see slightly different behavior, suggesting
that string arrays require (element_count*40 + 28) bytes. I get the
output below with 3.14.12 on linux-x86 for both ioc (with large
EPICS_CA_MAX_ARRAY_BYTES) and client (with EPICS_CA_MAX_ARRAY_BYTES
varying as shown).
HTH,
--Matt
~>cainfo Py:string2k Py:string64k
Py:string2k
State: connected
Host: vincent.cars.aps.anl.gov:5064
Access: read, write
Data type: DBR_STRING (native: DBF_STRING)
Element count: 2048
Py:string64k
State: connected
Host: vincent.cars.aps.anl.gov:5064
Access: read, write
Data type: DBR_STRING (native: DBF_STRING)
Element count: 65536
~>export EPICS_CA_MAX_ARRAY_BYTES=81947 ; caget Py:string2k
Read operation timed out: some PV data was not read.
Py:string2k*** CA error The requested data transfer is greater than
available memory or EPICS_CA_MAX_ARRAY_BYTES
~>export EPICS_CA_MAX_ARRAY_BYTES=81948 ; caget Py:string2k
Py:string2k 2048 ... (succeeds)
~>export EPICS_CA_MAX_ARRAY_BYTES=2621467 ; caget Py:string64k
Read operation timed out: some PV data was not read.
Py:string64k*** CA error The requested data transfer is greater than
available memory or EPICS_CA_MAX_ARRAY_BYTES
~>export EPICS_CA_MAX_ARRAY_BYTES=2621468 ; caget Py:string64k
Py:string64k 65536 ... (succeeds)
On Thu, Apr 21, 2011 at 6:13 PM, Jeff Hill <[email protected]> wrote:
>> It seems for DBF_STRING array there is certain
>> overhead, 16 bytes, when reading from CA client.
>> In your case, setting EPICS_CA_MAX_ARRAY_BYTES to
>> 2621416 works (but 2621415 didn’t work).
>
> As I recall, the size of the ca protocol header (16 bytes) _is_ implicitly
> added to the users request in EPICS_CA_MAX_ARRAY_BYTES so that such
> anomalies don’t occur, but perhaps I have neglected to add implicitly
> additional amounts for the larger (by 8 bytes) protocol header emitted when
> the request size is more than 0xffff bytes. Admittedly, this doesn’t yet
> fully explain the 15/16 transition of the issue that you are observing.
>
> In any case I have created a bug entry so that this issue can be tracked,
> and fixed.
>
> https://bugs.launchpad.net/epics-base/+bug/768670
>
> Jeff
> ______________________________________________________
> Jeffrey O. Hill Email [email protected]
> LANL MS H820 Voice 505 665 1831
> Los Alamos NM 87545 USA FAX 505 665 5107
>
> Message content: TSPA
>
> With sufficient thrust, pigs fly just fine. However, this is
> not necessarily a good idea. It is hard to be sure where they
> are going to land, and it could be dangerous sitting under them
> as they fly overhead. -- RFC 1925
>
>
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]]
>> On Behalf Of Wang Xiaoqiang
>> Sent: Thursday, April 21, 2011 2:23 PM
>> To: Ritesh Sugandhi
>> Cc: [email protected]
>> Subject: RE: Handling of String Array in CaChannel library
>>
>>
>> Hi,
>>
>> It seems for DBF_STRING array there is certain overhead, 16 bytes, when
>> reading from CA client. In your case, setting EPICS_CA_MAX_ARRAY_BYTES to
>> 2621416 works. I verified with caget from epics base
>>
>> [-bash SLSBASE=/work]$ export EPICS_CA_MAX_ARRAY_BYTES=2621415
>> [-bash SLSBASE=/work]$ /usr/local/epics/base/bin/SL5-x86/caget -d
>> DBR_STRING swave
>> Read operation timed out: some PV data was not read.
>> swave
>> *** CA error The requested data transfer is greater than available
>> memory or EPICS_CA_MAX_ARRAY_BYTES
>>
>> [-bash SLSBASE=/work]$ export EPICS_CA_MAX_ARRAY_BYTES=2621416
>> [-bash SLSBASE=/work]$ /usr/local/epics/base/bin/SL5-x86/caget -#10 -d
>> DBR_STRING swave
>> swave
>> Data type: DBR_STRING (native: DBF_STRING)
>> Element count: 10
>> Value:
>>
>> The reason behind should be answered by experts then.
>>
>> Best,
>> Xiaoqiang
>>
>>
>> -----Original Message-----
>> From: Ritesh Sugandhi [mailto:[email protected]]
>> Sent: Thu 4/21/2011 5:25 PM
>> To: Wang Xiaoqiang
>> Cc: [email protected]
>> Subject: Handling of String Array in CaChannel library
>>
>> Dear Sir,
>>
>> thanks for sharing the code, using your code I have mange to read and
>> write
>> array a simple array.
>>
>> I am able to successfully enhance the code to read and write a double
>> array
>> of size 64k ( 65535) elements. in this case I am using
>> EPICS_CA_MAX_ARRAY_BYTES configuration was 524280 ( i.e. 65535 * 8 bytes
>> for
>> double). this works successfully
>>
>> I have declared a string Array of 65535 elements and this time I have
>> setted
>> EPICS_CA_MAX_ARRAY_BYTES to 2621400 (i.e. 40*65535 considering size of 40
>> bytes for string) at server and client side. running with this gives error
>>
>> $ python2.6 ca-channel-v1.6-demo-waveform-string-64k.py
>> ('total values are', 65535)
>> The requested data transfer is greater than available memory or
>> EPICS_CA_MAX_ARRAY_BYTES
>> $
>>
>> but when I set EPICS_CA_MAX_ARRAY_BYTES to greater then 26214*20 at client
>> side.* I get the correct data at client side.
>>
>>
>> code is
>>
>> from CaChannel import *
>> from random import *
>> def main():
>> try:
>> channel = CaChannel('Py:string64k')
>> channel.searchw()
>> newval=[]
>> for i in range(65535):
>> newval.append("ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-$#")
>> channel.putw(newval)
>> print('total values are',channel.element_count())
>> print(channel.getw())
>> del channel
>> except CaChannelException, status:
>> print ca.message(status)
>> main()
>>
>> record is
>>
>> record(waveform, "Py:string64k")
>> {
>> field(DESC, "string array")
>> field(NELM, "65535")
>> field(FTVL, "STRING")
>> }
>>
>>
>>
>> -----------------------------------------------------------
>>
>>
>>
>>
>>
>> On Wed, Apr 20, 2011 at 4:21 PM, Wang Xiaoqiang
>> <[email protected]>wrote:
>>
>> >
>> > Hi,
>> >
>> > Load this into your IOC:
>> > record(waveform, "cawave")
>> > {
>> > field(DESC, "numeric array")
>> > field(NELM, "20")
>> > field(FTVL, "DOUBLE")
>> > }
>> >
>> > >>> import CaChannel
>> > >>> pv=CaChannel.CaChannel('cawave')
>> > >>> pv.searchw()
>> > >>> pv.getw()
>> > [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0,
>> 0.0,
>> > 0.0, 0.0, 0.0, 0.0, 0.0]
>> > >>> pv.putw(range(12))
>> > >>> pv.getw()
>> > [0.0, 1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0, 10.0, 11.0, 0.0, 0.0,
>> > 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
>> > >>>
>> >
>> > Xiaoqiang
>> > ------------------------------
>> > *From:* [email protected] [mailto:
>> > [email protected]] *On Behalf Of *Ritesh Sugandhi
>> > *Sent:* Wednesday, April 20, 2011 3:48 PM
>> > *To:* [email protected]
>> > *Subject:* Handling of Array in CaChannel library
>> >
>> > Dear Sir,
>> >
>> > Could I get an example of how to handle sub array and waveforms records
>> in
>> > CaChannel-v1.6 library code.
>> >
>> > Best regards,
>> >
>> > ritesh Sugandhi
>> >
>> >
>> >
>
>
>
>
<
- References:
- Handling of String Array in CaChannel library Ritesh Sugandhi
- RE: Handling of String Array in CaChannel library Wang Xiaoqiang
- RE: Handling of String Array in CaChannel library Jeff Hill
- Navigate by Date:
- Prev:
Re: PV not found Michael Davidsaver
- Next:
Re: VMIC VMIVME 4105 register cannot be modified? Andrew Johnson
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
<2011>
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: Handling of String Array in CaChannel library Jeff Hill
- Next:
Memory bank swap feature for SIS3301? Frank Hoeflich
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
<2011>
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|