g+
g+ Communities
Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014 
<== Date ==> <== Thread ==>

Subject: Problem using large arrays with Channel Access in EPICS 3.14.12
From: "Mark Rivers" <rivers@cars.uchicago.edu>
To: <tech-talk@aps.anl.gov>
Date: Tue, 11 Jan 2011 13:47:07 -0600
Folks,

There appears to be a serious problem with EPICS Channel Access when using large arrays in 3.14.12.

This is easy to demonstrate.  Simply load a waveform record with more than 64K elements, and then use cainfo to report on the record.  It does not matter what version of cainfo is used, 3.14.12, 3.14.11, 3.14.10 and 3.14.8.2 all show the same thing.  The problem is in the server.

I just built the example application from base, and loaded a 1 record database.
 
Here is the database:

corvette:example/iocBoot/iocexample>more test.template 
record(waveform, "TEST:waveform") {
   field(FTVL, "UCHAR")
   field(NELM, "2000000")
}

So it is a waveform record, type UCHAR, 2 million elements.

I have set EPICS_CA_MAX_ARRAY_BYTES to 20000000 (20 MB) on both client and server.
 
When I run the IOC and do caget on the NELM field of the waveform record I get the correct value:
 
corvette:areaDetector/iocBoot/iocProsilica>caget TEST:waveform.NELM
TEST:waveform.NELM             2e+06 

However, when I run cainfo I get 33920 for the element count:
 
corvette:areaDetector/iocBoot/iocProsilica>cainfo TEST:waveform
TEST:waveform
    State:         connected
    Host:          corvette.cars.aps.anl.gov:48884
    Access:        read, write
    Data type:     DBR_CHAR (native: DBF_CHAR)
    Element count: 33920
 
33920 is 2000000 modulo 65536.

I then did a systematic study and found that cainfo reports the correct element count up to 65535, but rolls over to 0 at 65536.  

Load the database with NELM=65535
corvette:areaDetector/iocBoot/iocProsilica>caget TEST:waveform.NELM
TEST:waveform.NELM             65535 
corvette:areaDetector/iocBoot/iocProsilica>cainfo TEST:waveform
TEST:waveform
    State:         connected
    Host:          corvette.cars.aps.anl.gov:5064
    Access:        read, write
    Data type:     DBR_CHAR (native: DBF_CHAR)
    Element count: 65535

Load the database with NELM=65536
corvette:areaDetector/iocBoot/iocProsilica>caget TEST:waveform.NELM
TEST:waveform.NELM             65536 
corvette:areaDetector/iocBoot/iocProsilica>cainfo TEST:waveform
TEST:waveform
    State:         connected
    Host:          corvette.cars.aps.anl.gov:5064
    Access:        read, write
    Data type:     DBR_CHAR (native: DBF_CHAR)
    Element count: 0

It thus appears that the high word for the native element count is set to 0 in 3.14.12.

This means that applications that send large arrays over Channel Access (e.g. areaDetector viewers) will not work in 3.14.12.

Interestingly the CAJ native Java library does not have a problem, and the ImageJ viewer in areaDetector does work.

Andrew Johnson is aware of the problem, so hopefully there will be a fix soon. :-)

Mark


 
________________________________________
From: Mark Rivers
Sent: Mon 1/10/2011 9:31 PM
To: johill@lanl.gov
Cc: anj@aps.anl.gov
Subject: FW: EPICS problem?
Hi Jeff,
 
I am having a problem with EPICS 3.14.12 that could be a Channel Access problem.  I am forwarding a message I sent to Andrew earlier this evening.  The problem happens on both Linux and Win32 IOCs.  The problem is that CA clients are reporting that the element count in a large array (NELM=4177920) is only 49152 bytes, which is incorrect.  The problem is not related to the version of the client: it happens with "cainfo" from 3.14.12, 3.14.11, 3.14.10 and 3.14.8.2.  It appears to be a problem with the server in 3.14.12?
 
This is what I see with the server built with 3.14.12:
 
corvette:ADApp/op/adl>/usr/local/epics/base-3.14.12/bin/linux-x86/cainfo 13PS1:image1:ArrayData
13PS1:image1:ArrayData
    State:            connected
    Host:             corvette.cars.aps.anl.gov:5064
    Access:           read, write
    Native data type: DBF_CHAR
    Request type:     DBR_CHAR
    Element count:    49152
When I run essentially the same IOC built with 3.14.10 I do not have this problem, cainfo (from 3.14.12) shows me the correct number of elements.  This is what I see with the server built with 3.14.10:
 
corvette:ADApp/op/adl>/usr/local/epics/base-3.14.12/bin/linux-x86/cainfo 13PS1:image1:ArrayData
13PS1:image1:ArrayData
    State:            connected
    Host:             corvette.cars.aps.anl.gov:5064
    Access:           read, write
    Native data type: DBF_CHAR
    Request type:     DBR_CHAR
    Element count:    4177920
Interestingly Java clients using the native Java CA library can read the entire array, while clients built with the C library seem only to be able to get the first 49152 bytes.  
 
In both cases NELM is 4177920:
 
corvette:ADApp/op/adl>/usr/local/epics/base-3.14.12/bin/linux-x86/caget 13PS1:image1:ArrayData.NELM
13PS1:image1:ArrayData.NELM    4.17792e+06
 
The server and the client both have EPICS_CA_MAX_ARRAY_BYTES = 20MB
epics> epicsPrtEnvParams
...
EPICS_CA_MAX_ARRAY_BYTES: 20000000
corvette:ADApp/op/adl>echo $EPICS_CA_MAX_ARRAY_BYTES
20000000
Any ideas?
Thanks,
Mark
 

________________________________________
From: Mark Rivers
Sent: Mon 1/10/2011 7:01 PM
To: 'Andrew Johnson'
Cc: 'Beamline Controls and Data Acquisition'
Subject: EPICS problem?
Hi Andrew,

I am having a strange problem with areaDetector in 3.14.12.  The image is a large waveform record:

epics> dbpr 13PS1:image1:ArrayData 5
ACKS: NO_ALARM      ACKT: YES           APST: Always        ASG:               
ASP: (nil)          BKPT: 00            BPTR: 0xb1c03008    BUSY: 0            
DESC:               DISA: 0             DISP: 0             DISS: NO_ALARM     
DISV: 1             DPVT: 0xb192c318    DSET: 0x884b314    
DTYP: asynInt8ArrayIn                   EGU:                EVNT: 0            
FLNK:CONSTANT 0     FTVL: UCHAR         HASH: 0             HOPR: 0            
INP:INST_IO @asyn(Image1,0,1)STD_ARRAY_DATA                 LCNT: 0            
LOPR: 0             LSET: 0xb193ede0   
MLIS: 00 00 00 00 00 00 00 00 00 00 00 00                   MLOK: d8 e4 01 b2  
MPST: Always        NAME: 13PS1:image1:ArrayData            NELM: 4177920      
NORD: 1392640       NSEV: NO_ALARM      NSTA: NO_ALARM      PACT: 0            
PHAS: 0             PINI: NO            PPN: (nil)          PPNR: (nil)        
PREC: 0             PRIO: LOW           PROC: 0             PUTF: 0            
RARM: 0             RDES: 0x97d00d0     RPRO: 0             RSET: 0x884c660    
SCAN: I/O Intr      SDIS:CONSTANT       SEVR: NO_ALARM      SIML:CONSTANT      
SIMM: NO            SIMS: NO_ALARM      SIOL:CONSTANT       SPVT: 0xb1602ab8   
STAT: NO_ALARM      TIME: 2011-01-10 18:54:13.484892926     TPRO: 0            
TSE: 0              TSEL:CONSTANT       UDF: 0              VAL: (nil)       

So NELM is 4177920.

This is epicsPrtEnvParams on the IOC:
epics> epicsPrtEnvParams
EPICS_AR_PORT: 7002
EPICS_CAS_AUTO_BEACON_ADDR_LIST is undefined
EPICS_CAS_BEACON_ADDR_LIST is undefined
EPICS_CAS_BEACON_PERIOD is undefined
EPICS_CAS_BEACON_PORT is undefined
EPICS_CAS_IGNORE_ADDR_LIST is undefined
EPICS_CAS_INTF_ADDR_LIST is undefined
EPICS_CAS_SERVER_PORT is undefined
EPICS_CA_ADDR_LIST is undefined
EPICS_CA_AUTO_ADDR_LIST: YES
EPICS_CA_BEACON_PERIOD: 15.0
EPICS_CA_CONN_TMO: 30.0
EPICS_CA_MAX_ARRAY_BYTES: 20000000
EPICS_CA_MAX_SEARCH_PERIOD: 300.0
EPICS_CA_NAME_SERVERS is undefined
EPICS_CA_REPEATER_PORT: 5065
EPICS_CA_SERVER_PORT: 5064
EPICS_CMD_PROTO_PORT is undefined
EPICS_IOC_LOG_FILE_COMMAND is undefined
EPICS_IOC_LOG_FILE_LIMIT: 10000000
EPICS_IOC_LOG_FILE_NAME: /home/epics/logs/IOC.log
EPICS_IOC_LOG_INET is undefined
EPICS_IOC_LOG_PORT: 7004
EPICS_TIMEZONE: CUS::360:031302:110602
EPICS_TS_NTP_INET is undefined
IOCSH_HISTSIZE: 50

So EPICS_CA_MAX_ARRAY_BYTES is 20MB, which is plenty large enough.

However, this is what cainfo reports:
corvette:ADApp/op/adl>/usr/local/epics/base-3.14.12/bin/linux-x86/cainfo 13PS1:image1:ArrayData
13PS1:image1:ArrayData
    State:            connected
    Host:             corvette.cars.aps.anl.gov:47430
    Access:           read, write
    Native data type: DBF_CHAR
    Request type:     DBR_CHAR
    Element count:    49152

Note that it reports Element count - 49152, which is completely wrong.

Caget reports the same thing:
corvette:ADApp/op/adl>/usr/local/epics/base-3.14.12/bin/linux-x86/caget 13PS1:image1:ArrayData | more
13PS1:image1:ArrayData 49152 32 32 31 32 32 33 32 33 32 33 32 31 31 31 31 32 32 32 31 31 32 33 32 33 33 33 33 33 33 33 33 32 32 33 33 32 32 32 33 33 34 33 33 33 33 32 31 31
 32 32 31 31 32 31 31 30 31 29 30 30 30 28 28 26 27 26 26 23 24 2

If I try to read the array in IDL I only get 49152 bytes.  But if I read it in Java, using my ImageJ plugin, I get the entire array.

Something is wrong!

Mark


Replies:
Re: Problem using large arrays with Channel Access in EPICS 3.14.12 Till Straumann

Navigate by Date:
Prev: Re: CSS Data Browser Plot Problem Kasemir, Kay
Next: Re: Problem using large arrays with Channel Access in EPICS 3.14.12 Till Straumann
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014 
Navigate by Thread:
Prev: Re: PV Mapping Using Java Annotations Mitch McCuiston
Next: Re: Problem using large arrays with Channel Access in EPICS 3.14.12 Till Straumann
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICSv4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·