Hi All,
Last fall there was a thread here about Python extensions for Epics
Channel Access, especially noting that there were many alternative
implementations, several (including my own) with some shortcomings.
The discussion led to whether there could be some common interface
code.
I have completely rewritten my Python extension Channel Access, and
believe it is now ready for use. While primarily intended to replace
my EpicsCA library, I believe this interface has most of the features
desired in the discussion last fall. I'm hoping that this can lead to
better collaboration. Code for PyEpics3 is at
http://cars.uchicago.edu/software/python/pyepics3/
On-line documentation is at
http://cars.uchicago.edu/software/python/pyepics3/doc
There is more to do, but I would welcome any comments, complaints, or
suggestions. In particular, I am interested in knowing if changes or
additions to the low-level API that would satisfy those using other
implementations. For those interested, some more details are given
below.
Thanks,
--Matt Newville <newville at cars.uchicago.edu>
The main features of this implementation are:
1. uniformly, consistentlyuses 3.14 API.
2. enables preemptive callbacks by default.
3. uses Python ctypes library, which directly accesses the Com and ca
shared object libraries. There is *NO* C code or dependencies on SWIG.
The module is *pure* Python, and goes directly to the DLL.
4. provides a fairly complete, low-level set of routines with API and
behavior very similar to the C library.
5. provides higher-level object for a Process Variable.
6. Has no dependencies on third-party modules besides Epics base.
7. Support for both Python 3 and Python 2.
8. follow Python standards for ease of installation, coding conventions,
documentation, and (incomplete) unit-testing.
For implementation and support, using Python's ctypes is the most
significant change and improvement. As an important example, having
no C code makes support for Windows trivial: the source distribution
includes and installs pre-compiled Com.dll and ca.dll (for 32-bit
Windows) so that the normal installation procedure:
python setup.py install
works for both Unix and Windows. Python Channel Access works on
Windows with no other Epics installation or compiler needed. On Unix,
it is assumed that libCom.so and libca.so from Epics base are
installed and can be found at run-time. This means that one can
upgrade Epics, and the python module will use the new version the next
time it is loaded.
Using preemptive callbacks and proper connection callbacks mean that
the library is much faster (than my previous version, anyway) at
connecting to many PVs. The high level PV object is greatly
simplified as well, with some API changes (all for the better), in
particular in the way user-defined callbacks are called, and in the
automatic fetching of control values for PVs.
By using ctypes, thread-safety is greatly improved. The Python
interpreter prevents multiple threads from simultaneous accessing
global data (such as the memory locations of callback functions), but
cannot automatically do this for C extension code. This would add a
layer of complication to the C "wrapper", but the ctypes module
handles this automatically.
There is also some support code for GUIs using wxPython, and for
higher-level objects based on groups of PVs.
There are a few missing low-level Channel Access features, and some
changes to Channel Access API. Not all DBR_* variants are supported:
The "primitive types" are all supported as are DBR_TIME_<*> and
DBR_CTRL_<*> types, but DBR_GR_<*>, DBR_STS_<*>, and DBR_PUT_ACK<*>
types are not. The call signature to some ca_* functions have been
changed to be more "python-like", and some functions are not
implemented. In particular, error handling is done in a more
python-like manner, raising an Exception instead of expecting the user
to check return status codes with SEVCHK(): a PySEVCHK() replaces this
to raise an Exception on an unexpected return status from a ca_* C
function.
PyEpics3 works with Python 2.5, 2.6, and 3.1. Python 3 is a major
re-write of Python, breaking backward compatibility of some syntax,
many features, and the C API. The most important change for Epics CA
is that arrays of bytes (C char*) are now different from strings, as
strings in Python3 are always unicode. By adding one test for Python
version, the source code for PyEpics3 works with Python 3.1 and Python
2.*. More testing with Python3 will be needed when numpy and wxPython
are available.
I've been using a version of this code for the past month or more, in
real data collection, and it has worked well. I am not yet using it
all my production code, but I plan on migrating to this. There are
missing features, and there may be bugs, but there are also tests and
documentation. Again, I would be happy to hear suggestions for
improvement or collaboration.
- Navigate by Date:
- Prev:
RE: cac_select_io Segmentation fault Al Honey
- Next:
does anyone has the driver for Galil Motion Controller DMC-B140? Silver
- 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: EDM text entry: segmentation fault Dmitry Teytelman
- Next:
does anyone has the driver for Galil Motion Controller DMC-B140? Silver
- 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
|