Experimental Physics and
Industrial Control System

Hi All,

Getting

>   >>> import epics
>   >>> from epics import caget, caput
>   >>> m1 = caget('lyx:ai3')
>   cannot connect to lyx:ai3

means that the CA library was found and loaded. Otherwise you'd get a ChannelAccessException that said it could not find the CA dynamic library, or could not load it due to some conflict.   In more detail, the "cannot connect" message means that the connection callback function passed to ca_create_channel() for the PV named 'lyx:ai3' did not run before timing out (with a default timeout of 5 seconds).  Like Ricardo says, that is most likely due to things like an IOC that was not running or not in the address list or a mis-spelled PV name.

Like Andrew says, pyepics relies on libca dynamic library, which in turns relies on libCom.  But I should probably clarify how libca is found and loaded, especially because this has changed over the past few years. 

1. if PYEPICS_LIBCA is defined and points to a valid dynamic library for libca.so (or ca.dll, libca.dylib depending on system), that will be loaded and used.  In turn that libca will need to find and load libCom.  That gives complete control over which library is used to anyone who wants it.

2. if there is a valid libca included in the python-specific folder where pyepics is installed, that will be used.  That is, pyepics distributes and installs working shared libraries for libca and libCom for darwin, 32- and 64-bit windows, and 32- and 64-bit linux (and for linux-arm in the master branch).  These will typically live in a place like .../lib/python3.6/site-packages/pyepics/clibs/linux64/libca.so, and that libca has been fixed (with patchelf on linux) to point to the libCom in same folder.

3. if there is no installed libca or it cannot be loaded, PATH and LD_LIBRARY_PATH will be searched for libca, and finally the Python ctypes library "find library" function (which appears to be slightly different from using PATH and LD_LIBRARY_PATH, at least on some systems) will be used.   This is sort of a last-ditch effort.

The versions of libca / libCom that are included in the distribution should be used by default. These are the libraries we test with, and we recommend using these.   We've included Windows DLLs for a very long time and recently added Linux shared libraries partly in recognition that linux ((like Windows and Mac OSX) is often a client so that even requiring Epics base was something of a burden, and partly due to a conflict with readline.  

--Matt Newville

PS: A few more details...  By default, libCom links against libreadline and CA requires libCom even though CA does not use readline.  It is perfectly reasonable to expect an environment like python to use readline.  And, of course python would never be able to load  libca / libCom built with a conflicting readline.  Such conflicts do happen, especially for non-system Python implementations such as Anaconda which may build with a version of readline that is different from the one epics base chooses.   Using non-system-installed environments is highly recommended, especially since a *user* can install Anaconda Python and pyepics without root privileges.   But, to disable linking against readline, one *must* edit configure/os/CONFIG_SITE.Common.linux-x86_64.   There are over 200 files in configure/os/, around 100 of them have 'linux' in the name, several of those contain the word READLINE in them somewhere.   We do not want to require pyepics users to know how to configure and build epics base with non-default settings, so to work around this, we build epics base without readline and distributes these libca / libCom with pyepics, and recommend using these.