Experimental Physics and
Industrial Control System

Matt Newville <[email protected]> · Wed, 22 Sep 2010 06:38:11 -0500

Hi Emmanuel,

Sorry for the trouble (and I do read tech-talk, sometimes early in the
morning).  I don't see that behavior, at least on the first machine I
tested it on (linux-x86).  Using both python2.6 and python3.1, I get
the expected values for longs:

millenia:~>caget 13XRM:m1.RRBV
13XRM:m1.RRBV                  -20000

millenia:~>python
Python 2.6 (r26:66714, Nov  3 2009, 17:33:38)
[GCC 4.4.1 20090725 (Red Hat 4.4.1-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
Imported history from: '/home/newville/.pyhist'
>>> import epics
>>> epics.__version__
'3.0.8'
>>> p = epics.PV('13XRM:m1.RRBV')
>>> print p.info
== 13XRM:m1.RRBV  (native_long) ==
   value      = -20000
   char_value = '-20000'
   count      = 1
   type       = long
   units      = mm
   host       = sonata.cars.aps.anl.gov:5064
   access     = read-only
   status     = 0
   severity   = 0
   timestamp  = 1285154637.998 (2010-09-22 06:23:57.998245)
   upper_ctrl_limit    = 1240000
   lower_ctrl_limit    = -1240000
   upper_disp_limit    = 1240000
   lower_disp_limit    = -1240000
   upper_alarm_limit   = 0
   lower_alarm_limit   = 0
   upper_warning_limit = 0
   lower_warning_limit = 0
   PV is internally monitored, with 0 user-defined callbacks:
=============================

I don't think it's an issue with the version of pyepics, as nothing
has changed in the mapping of the Epics database types to the  python
ctypes types:  An Epics DBR_LONG becomes a ctypes.c_long.

What system are you working on, and how were Epics base and python
built? Could this be an issue with 64bit machines?

Sorry for the trouble,

--Matt Newville <newville at cars.uchicago.edu> 630-252-0431

On Wed, Sep 22, 2010 at 12:27 AM,  <[email protected]> wrote:
> Hello,
>
> I have been using epics and python for quite some time now.
> Just recently I moved to the excellent pyepics.
> The only issue... long type PVs!
> I am about to upgrade to the latest version (pyepics 3,0,8) since I am using an older one (3.0.1)
>
> But here is what I see:
>
>
> epics2@cr1com1 $ caget DMC2183:1:AEncdrPstnLI
> DMC2183:1:AEncdrPstnLI         -1833
>
> in python:
> -------> print(pv.info)
> == DMC2183:1:AEncdrPstnLI  (long) ==
>   value      = 4294965463
>   char_value = 4294965463
>   count      = 1
>   type       = long
>   units      = Steps
>   host       = cls1ir-eth0:5064
>   access     = read/write
>   status     = 0
>   severity   = 0
>   timestamp  = 1285131880.264 (2010-09-21 22:04:40.263942)
>   upper_ctrl_limit    = 0
>   lower_ctrl_limit    = 0
>   upper_disp_limit    = 0
>   lower_disp_limit    = 0
>   upper_alarm_limit   = 0
>   lower_alarm_limit   = 0
>   upper_warning_limit = -7872675053568
>   lower_warning_limit = 0
>   PV is internally monitored, with 0 user-defined callbacks:
> =============================
>
> Notice the reported value as ...
>   value      = 4294965463
>
> It seems there is an issue with bit ordering.
> It works well for double records though.s ;-)
>
> Based on the pdf doc, the maintainer is Matthew Newville at U Chicago.
> Is he on the mailing list? Anyone knows how to contact him?
> I should have contacted him a long time ago....
>
> Best,
> --
> Emmanuel
>
>
>
>
> -
> Emmanuel
>
>

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System