Experimental Physics and
Industrial Control System

Also, is your IOC running EPICS Base version R3.14.12 and if so have you
installed the patch from the item dated 2011-01-13 on the Known Problems page
at http://www.aps.anl.gov/epics/base/R3-14/12-docs/KnownProblems.html

Without the patch an R3.14.12 IOC should be able to transfer up to 65534
elements but not 65535 or larger.

- Andrew

On Tuesday 12 April 2011 10:55:38 Mark Rivers wrote:
> It's actually EPICS_CA_MAX_ARRAY_BYTES, not EPICS_CA_MAX_ARRAY_SIZE.  That
>  must be set on both the IOC machine and the Python client machine.
>
> Mark
>
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
>  On Behalf Of Matt Newville Sent: Tuesday, April 12, 2011 10:52 AM
> To: Ritesh Sugandhi
> Cc: [email protected]
> Subject: Re: Python EPICS interface (pyepics 3.1.1) double waveform record
>  (NLEM = 65535 ) record handling exception
>
> Hi Ritesh,
>
> What is EPICS_CA_MAX_ARRAY_SIZE set to?  If left unset, I believe you
> would see exactly this behavior (arrays using up to 16384 bytes would
> work, while larger arrays would fail.
>
> I haven't tested with python 3.2 on 64-bit linux (yet?), so it's
> possible there are issues, but I'd expect that if short arrays of
> doubles work that longer ones would too.
>
> --Matt Newville
>
> On Tue, Apr 12, 2011 at 10:29 AM, Ritesh Sugandhi
>
> <[email protected]> wrote:
> > Dear sir,
> >
> > My Enviorment is
> > ----------------------
> > pyepics-3.1.1,
> > python 3.2
> > Linux kernal  2.6.18-194 ; 64 bit
> > Context: Testing pyepics library
> > Problem:
> > I am using supplied database (test/pydebug.db) and I am not able to use
> > the double wave form record of 64k elements. while double wave form
> > record of 2k elements works fine.
> > Any suggestion are welcome.
> > Best regards
> > ---- EPICS shell------------------
> > epics> dbpr Py:double64k 2
> > ACKS: NO_ALARM      ACKT: YES           APST: Always        ASG:
> >
> > BKPT: 00            BUSY: 0             DESC: long double waveform
> >
> > DISA: 0             DISP: 0             DISS: NO_ALARM      DISV: 1
> >
> > DTYP: Soft Channel  EGU:                EVNT: 0             FLNK:CONSTANT
> > 0
> >
> > FTVL: DOUBLE        HOPR: 0             INP:CONSTANT        LCNT: 0
> >
> > LOPR: 0             MPST: Always        NAME: Py:double64k  NELM: 65536
> >
> > NORD: 0             NSEV: NO_ALARM      NSTA: NO_ALARM      PACT: 0
> >
> > PHAS: 0             PINI: NO            PREC: 0             PRIO: LOW
> >
> > PUTF: 0             RARM: 0             RPRO: 0             SCAN: Passive
> >
> > SDIS:CONSTANT       SEVR: INVALID       SIML:CONSTANT       SIMM: NO
> >
> > SIMS: NO_ALARM      SIOL:CONSTANT       STAT: UDF           TIME:
> > <undefined>
> > TPRO: 0             TSE: 0              TSEL:CONSTANT       UDF: 1
> >
> > VAL: (nil)
> > ------------- Python shell -----------------------------
> >
> >>>> pv1=PV('Py:double64k')
> >
> > Traceback (most recent call last):
> >   File "_ctypes/callbacks.c", line 259, in 'calling callback function'
> >   File
> > "/home/ITER/sugandr/Desktop/epics-python/Python-3.2/lib/python3.2/site-pa
> >ckages/epics/ca.py", line 391, in _onGetEvent
> >
> >>>>     value = dbr.cast_args(args).contents
> >
> > ValueError: NULL pointer access
>

--
An error is only a mistake if you don't learn from it.
When you learn something from it, it becomes a lesson.