We Keep Coding

PyVISA not listing USB instrument on Linux

I am trying to communicate with a LeCroy WaveRunner 640Zi oscilloscope from a Raspberry Pi, they are connected with a USB cable. I have already done this under Windows, but now I am not able to make it work in Linux.
If I run lsusb I see this:
$ lsusb
Bus 001 Device 009: ID 05ff:1023 LeCroy Corp.
...
If I now go to Python I get this:
$ python3
Python 3.7.3 (default, Dec 20 2019, 18:57:59)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pyvisa
>>> pyvisa.ResourceManager().list_resources()
('ASRL/dev/ttyAMA0::INSTR',)
>>>
The oscilloscope is not there (the ASRL/dev/ttyAMA0::INSTR I think is something from the Raspberry Py itself). The oscilloscope is properly configured, I think, because if I go to the options (using the screen from the scope itself) and go to "remote options" I see that it is set up for USB and the VISA address is USB0::bla::bla::bla::INSTR.
I tried to proceed as explained in this page but did not work. If I run python3 -m visa info I get
$ python3 -m visa info
~/.local/lib/python3.7/site-packages/visa.py:23: FutureWarning: The visa module provided by PyVISA is being deprecated. You can replace `import visa` by `import pyvisa as visa` to achieve the same effect.
The reason for the deprecation is the possible conflict with the visa package provided by the https://github.com/visa-sdk/visa-python which can result in hard to debug situations.
FutureWarning,
Machine Details:
Platform ID: Linux-4.19.97-v7+-armv7l-with-debian-10.3
Processor:
Python:
Implementation: CPython
Executable: /usr/bin/python3
Version: 3.7.3
Compiler: GCC 8.3.0
Bits: 32bit
Build: Dec 20 2019 18:57:59 (#default)
Unicode: UCS4
PyVISA Version: 1.11.3
Backends:
ivi:
Version: 1.11.3 (bundled with PyVISA)
Binary library: Not found
py:
Version: 0.5.2
ASRL INSTR: Available via PySerial (3.4)
USB INSTR: Available via PyUSB (1.0.2). Backend: libusb1
USB RAW: Available via PyUSB (1.0.2). Backend: libusb1
TCPIP INSTR: Available
TCPIP SOCKET: Available
GPIB INSTR:
Please install linux-gpib (Linux) or gpib-ctypes (Windows, Linux) to use this resource type. Note that installing gpib-ctypes will give you access to a broader range of funcionality.
No module named 'gpib'
I have also tried to connect with the oscilloscope without "listing the resources" by doing pyvisa.ResourceManager().open_resource('USB0::bla::bla::bla::INSTR') but I get:
>>> osc = pyvisa.ResourceManager().open_resource('USB0::0x05ff::0x1023::2810N60091::INSTR')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "~/.local/lib/python3.7/site-packages/pyvisa/highlevel.py", line 3304, in open_resource
res.open(access_mode, open_timeout)
File "~/.local/lib/python3.7/site-packages/pyvisa/resources/resource.py", line 298, in open
self._resource_name, access_mode, open_timeout
File "~/.local/lib/python3.7/site-packages/pyvisa/highlevel.py", line 3232, in open_bare_resource
return self.visalib.open(self.session, resource_name, access_mode, open_timeout)
File "~/.local/lib/python3.7/site-packages/pyvisa_py/highlevel.py", line 167, in open
sess = cls(session, resource_name, parsed, open_timeout)
File "~/.local/lib/python3.7/site-packages/pyvisa_py/sessions.py", line 323, in __init__
self.after_parsing()
File "~/.local/lib/python3.7/site-packages/pyvisa_py/usb.py", line 84, in after_parsing
self.parsed.serial_number,
File "~/.local/lib/python3.7/site-packages/pyvisa_py/protocols/usbtmc.py", line 287, in __init__
super(USBTMC, self).__init__(vendor, product, serial_number, **kwargs)
File "~/.local/lib/python3.7/site-packages/pyvisa_py/protocols/usbtmc.py", line 199, in __init__
raise ValueError("No device found.")
ValueError: No device found.
>>>

I managed to find a solution which I share for the sake of future generations to come. I had just to add a line to the file /etc/udev/rules.d/99-com.rules with the content SUBSYSTEM=="usb", MODE="0666", GROUP="usbusers" (or append this line in case the file already exists) and then restart the computer. In summary:
Enter into the sudo environment:
sudo su
Now add the required line into the respective file:
echo 'SUBSYSTEM=="usb", MODE="0666", GROUP="usbusers"' >> /etc/udev/rules.d/99-com.rules
Restart the computer.
Enjoy.
$ python3
Python 3.7.3 (default, Dec 20 2019, 18:57:59)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pyvisa
>>> pyvisa.ResourceManager().list_resources()
('ASRL/dev/ttyAMA0::INSTR', 'USB0::bla::bla::bla::INSTR')
>>> osc = pyvisa.ResourceManager().open_resource('USB0::bla::bla::bla::INSTR')
>>> osc.query('*IDN?')
'*IDN LECROY,WR640ZI,LCRY28blablabla,7.7.1\n'

Python Evdev binding for OpenWrt

Good day,
I'm a student and I would just like to ask for a minute of your time.
I'm working on a barcode reader connected via USB port to a board name Arduino Yun. This board runs a version of embedded linux derived from OpenWrt using a microprocessor named Atheros AR9331
I would like to ask you, what's necessary to make the Python Evdev binding (python-evdev.readthedocs.org/en/latest/), to be able to run in this type of MIPS microarchitecture? At the momento, it's only for Ubuntu and ArchLinux.
I'm kind of guessing that cross compilation would be needed, or the indication of the usage of a specific C compiler inside this linux.
The current python version supported for OpenWrt is 2.7.3
I already know , if you compile C code in your PC, the resulting executable will only run in this type of architecture. If you use that compiled program inside the microprocessor, it wont work.
I've used this binding without trouble within ubuntu in my PC. I followed the instructions, python setup.py install, with a previous installation of setuptools, and it worked just fine.
But regarding OpenWrt, this was not the case.
The python script I'm using requires this library within the first line of code in order to reach the data from the device (it works like a keyboard /dev/input/event0):
#!/usr/bin/env python
from evdev import InputDevice, ecodes, list_devices
from select import select
I've seen suggestions of copying the entire library inside the arduino, and run the script inside the same folder. But it doesn't work, since the evdev module has files created with the architecture of the PC and not the MIPS.
So, what are the messages displayed for the error?
If you run python setup.py install in Openwrt to try to install the evdev binding, this appears on screen:
File "setup.py", line 10, in <module>
from setuptools.command.develop import develop
ImportError: No module named setuptools.command.develop
It's obvious from here that you need the module aforementioned. So, I tried to install it with this script (pypi.python.org/pypi/setuptools):
python ez_setup.py
And the output shows this:
Downloading https://pypi.python.org/packages/source/s/setuptools/setuptools-11.3.1.zip
Traceback (most recent call last):
File "ez_setup.py", line 332, in <module>
sys.exit(main())
File "ez_setup.py", line 327, in main
downloader_factory=options.downloader_factory,
File "ez_setup.py", line 287, in download_setuptools
downloader(url, saveto)
File "ez_setup.py", line 209, in download_file_curl
_clean_check(cmd, target)
File "ez_setup.py", line 169, in _clean_check
subprocess.check_call(cmd)
File "/usr/lib/python2.7/subprocess.py", line 511, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['curl','https://pypi.python.org/packages/source/s/setuptools/setuptools-11.3.1.zip', '--silent', '--output', '/mnt/sda1/evdev-0.4.6/setuptools-11.3.1.zip']' returned non-zero exit status 60
I pressume this output is due to the fact that pypi doesn't exist for the python 2.7.3 in OpenWrt , only for newer versions and other architectures. Evedv binding is requiring the setuptools module in order to make things easier and standard, but if the binding is not supported for the target architecture, what's needed to be able to use it anyways?
Thanks for your time,

Good day everyone,
The solution was provided by Georgi Valkov. He is the creator of the python-evdev binding. I contacted him directly, and he was so kind that he cross compiled a version for the OpenWrt / Yun .
You can install the package using the openwrt package manager - opkg. The installation process is along the lines of:
$ opkg update
$ opkg install /path/to/python-evdev_0.4.7-1_ar71xx.ipk
To verify that the install was successful:
$ opkg files python-evdev
/usr/lib/python2.7/site-packages/evdev-0.4.7-py2.7.egg-info
/usr/lib/python2.7/site-packages/evdev/genecodes.py
/usr/lib/python2.7/site-packages/evdev/ff.py
/usr/lib/python2.7/site-packages/evdev/_input.so
/usr/lib/python2.7/site-packages/evdev/device.py
/usr/lib/python2.7/site-packages/evdev/events.py
/usr/lib/python2.7/site-packages/evdev/__init__.py
/usr/lib/python2.7/site-packages/evdev/ecodes.py
/usr/lib/python2.7/site-packages/evdev/_ecodes.so
/usr/lib/python2.7/site-packages/evdev/util.py
/usr/lib/python2.7/site-packages/evdev/uinput.py
/usr/lib/python2.7/site-packages/evdev/_uinput.so
This works just fine. Thanks.
PS. If someone needs the file, please contact me. Georgi sent me this address, but I didn't download the file from there because he sent it to me over email.
https://github.com/gvalkov/openwrt-packages-yun/blob/master/lang/python-evdev/Makefile

In the output, you can see that curl returned the status code 60. According to man curl
60 Peer certificate cannot be authenticated with known CA certifi‐
cates.
According to the setuptools page, you can instead use python ez_setup.py --insecure but obviously do that at your own risk. Alternatively you could do what the advanced instructions say and manually download the setuptools tarball, verify its md5 hash yourself, and install it using its setup.py .

Can't import the cx_Oracle module unless I'm using an interactive shell

When using Python on an interactive shell I'm able to import the cx_Oracle file with no problem. Ex:
me#server~/ $ python
Python 2.7.6 (default, Mar 22 2014, 22:59:56)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import cx_Oracle
>>>
As you can see, importing works without a hitch. However, when I try to run a Python script doing the same thing, I get an error:
me#server~/ $ sudo script.py
Traceback (most recent call last):
File "/usr/local/bin/script.py", line 19, in <module>
import cx_Oracle
ImportError: No module named "cx_Oracle'
Here is the important section from script.py:
# 16 other lines above here
# Imports
import sys
import cx_Oracle
import psycopg2
...
I'm befuddled here. Other pertinent information is the server I'm running is Ubuntu 14.04.1 LTS (upgraded from 12.04) 64bit. which python and sudo which python both point to the same location. Also, doing this as root via sudo su - gets the same results; import OK from interactive but error from script.
Nothing other than the OS upgrade happened between when this worked and when it stopped working.

Sorry, all. This was a silly on my part. Turns out the script in question was using Python3, and when the server upgraded, Python3 went from being 3.2 version to being 3.4 version.
Once the cx_Oracle module was set up in the 3.4 version, everything worked as expected.
Phil, your final note talking about the shebang was what lead me to discover this, so kudos to you! The reason I didn't mark your response as the answer was because technically it wasn't but led me on the right path.
Cheers!

sudo starts a new bash environment which is then pointing to a different python executable (different installed modules).
You can verify this with which python and sudo which python
EDIT: so if they point to the same executable, then you should look at sys.path to find differences. In both environemnts you can:
python -c "import sys; print('\n'.join(sys.path))"
sudo python -c "import sys; print('\n'.join(sys.path))"
Look for differences. If there are none:
A common error in import situations like this is that python will first look at the local dir. So if you happen to be running python and importing something what is found locally (i.e. cx_Oracle is a subdir of your current location), you will get an import error if you change directories.
Final note: I have assumed here that the shbang of the script.py points to the same executable as which python. That is, that python script.py and script.py return the same error.

python import cx_Oracle error on cygwin

I tried to install cx_Oracle from pypi source since there is no available port for it in cygwin. I did make some changes as suggested in http://permalink.gmane.org/gmane.comp.python.db.cx-oracle/2492 and modified my setup.py. However, I still get the following error :-
$ python
Python 2.7.3 (default, Dec 18 2012, 13:50:09)
[GCC 4.5.3] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import cx_Oracle
/usr/lib/python2.7/site-packages/cx_Oracle-5.1.3-py2.7-cygwin-1.7.24-i686.egg/cx_Oracle.py:3: UserWa
rning: Module cx_Oracle was already imported from /usr/lib/python2.7/site-packages/cx_Oracle-5.1.3-p
y2.7-cygwin-1.7.24-i686.egg/cx_Oracle.pyc, but /home/zerog/cx_Oracle-5.1.3 is being added to sys.pat
h
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "build/bdist.cygwin-1.7.24-i686/egg/cx_Oracle.py", line 7, in <module>
File "build/bdist.cygwin-1.7.24-i686/egg/cx_Oracle.py", line 6, in __bootstrap__
ImportError: Exec format error
>>>
If someone can please help me fix this ?
TIA.

Fixed this by specifying the path to instantclient as below :
$ export PATH=$PATH:/cygdrive/d/Tools/instantclient_11_2
(Other, possibly important stuff) :
$ echo $LD_LIBRARY_PATH
/cygdrive/d/Tools/instantclient_11_2
$ echo $ORACLE_HOME
/cygdrive/d/Tools/instantclient_11_2
Now, I get :-
$ python
Python 2.7.3 (default, Dec 18 2012, 13:50:09)
[GCC 4.5.3] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import cx_Oracle
>>>

It's hard to pin down from the error message alone, but I am guessing that you have two different copies of cx_Oracle in your sys.path. The error message is complaining that a different version of the same module had already been import-ed.
Presumably the pristine upstream version is installed system-wide in /usr/lib/python2.7/site-packages/cx_Oracle-5.1.3-py2.7-cygwin-1.7.24-i686.egg, and your modified version in /home/zerog/cx_Oracle-5.1.3.
Does it work if you pare down sys.path so that only the original, or only your modified version, is included?
(You might want to use virtualenv if you need to switch back and forth between two versions frequently.)

I ran into this error "Exec format error."
For me, this was likely caused by a mismatch between cygwin being installed as 64 bit, but the instant client being installed as 32 bit. Double check that everything (oracle, cygwin) is either 32 bit or 64 bit.
What fixed my issue:
Since my cygwin is 64 bit (see uname -a, and look for x86_64), I downloaded the 64 bit instant client from oracle's website, and unzipped
I set the env vars in .profile, to point where it was unzipped:
export ORACLE_HOME=/cygdrive/c/oracle/instantclient_x64_11_2
export LD_LIBRARY_PATH=$ORACLE_HOME
export DYLD_LIBRARY_PATH=$ORACLE_HOME
export TNS_ADMIN='//optional/path/to/your/oracle/tns/files/'
source ~/.profile
To test, you should now be able to run this python command with no error:
import cx_Oracle
To verify the path is correct, if you run ls, you should see something like
ls $ORACLE_HOME
adrci.exe genezi.exe oci.sym ociw32.dll ojdbc6.jar
oraocci11.dll oraociei11.sym uidrvci.exe vc9
adrci.sym genezi.sym ocijdbc11.dll ociw32.sym orannzsbb11.dll
oraocci11.sym orasql11.dll uidrvci.sym xstreams.jar
BASIC_README oci.dll ocijdbc11.sym ojdbc5.jar orannzsbb11.sym
oraociei11.dll orasql11.sym vc8

How can I use Django with MySQL in MAMP stack?

I have difficulty especially in installing MySQLdb module (MySQL-python-1.2.3c1), to connect to the MySQL in MAMP stack.
I've done a number of things such as copying the mysql include directory and library (including plugin) from a fresh installation of mysql (version 5.1.47) to the one inside MAMP (version 5.1.37).
Now, the MySQLdb module build and install doesnt give me error.
The error happens when I'm calling 'import MySQLdb' from python shell (version 2.6).
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "build/bdist.macosx-10.6-universal/egg/MySQLdb/__init__.py", line 19, in <module>
File "build/bdist.macosx-10.6-universal/egg/_mysql.py", line 7, in <module>
File "build/bdist.macosx-10.6-universal/egg/_mysql.py", line 6, in __bootstrap__
ImportError: dlopen(/Users/rhenru/.python-eggs/MySQL_python-1.2.3c1-py2.6-macosx-10.6-universal.egg-tmp/_mysql.so, 2): Symbol not found: _mysql_affected_rows
Referenced from: /Users/rhenru/.python-eggs/MySQL_python-1.2.3c1-py2.6-macosx-10.6-universal.egg-tmp/_mysql.so
Expected in: flat namespace
in /Users/rhenru/.python-eggs/MySQL_python-1.2.3c1-py2.6-macosx-10.6-universal.egg-tmp/_mysql.so
Any idea, what else do I need to do to make it works?
Thanks a bunch,
Robert
=========
Add the system response after using virtualenv as suggested by Hank Gay below...
(MyDjangoProject)MyMacPro:MyDjangoProject rhenru$ which python
/Users/rhenru/Workspace/django/MyDjangoProject/bin/python
After I run python in virtualenv, importing MySQLdb:
>>> import MySQLdb
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "build/bdist.macosx-10.6-universal/egg/MySQLdb/__init__.py", line 19, in <module>
File "build/bdist.macosx-10.6-universal/egg/_mysql.py", line 7, in <module>
File "build/bdist.macosx-10.6-universal/egg/_mysql.py", line 6, in __bootstrap__
ImportError: dlopen(/Users/rhenru/.python-eggs/MySQL_python-1.2.3c1-py2.6-macosx-10.6-universal.egg-tmp/_mysql.so, 2): Symbol not found: _mysql_affected_rows
Referenced from: /Users/rhenru/.python-eggs/MySQL_python-1.2.3c1-py2.6-macosx-10.6-universal.egg-tmp/_mysql.so
Expected in: flat namespace
in /Users/rhenru/.python-eggs/MySQL_python-1.2.3c1-py2.6-macosx-10.6-universal.egg-tmp/_mysql.so
import sys and sys.path
>>> import sys
>>> print sys.path
['', '/Users/rhenru/Workspace/django/MyDjangoProject/lib/python2.6/site-packages/distribute-0.6.10-py2.6.egg', '/Users/rhenru/Workspace/django/MyDjangoProject/lib/python2.6/site-packages/pip-0.7.1-py2.6.egg', '/Users/rhenru/Workspace/django/MyDjangoProject/lib/python26.zip', '/Library/Python/2.6/site-packages/PyXML-0.8.4-py2.6-macosx-10.6-universal.egg', '/Library/Python/2.6/site-packages/pydot-1.0.2-py2.6.egg', '/Library/Python/2.6/site-packages/pyparsing-1.5.2-py2.6.egg', '/Library/Python/2.6/site-packages/vobject-0.8.1c-py2.6.egg', '/Library/Python/2.6/site-packages/pytz-2010h-py2.6.egg', '/Library/Python/2.6/site-packages/MySQL_python-1.2.3c1-py2.6-macosx-10.6-universal.egg', '/Library/Python/2.6/site-packages/distribute-0.6.12-py2.6.egg', '/Library/Python/2.6/site-packages/pip-0.7.1-py2.6.egg', '/Users/rhenru/Workspace/django/MyDjangoProject/lib/python2.6', '/Users/rhenru/Workspace/django/MyDjangoProject/lib/python2.6/plat-darwin', '/Users/rhenru/Workspace/django/MyDjangoProject/lib/python2.6/plat-mac', '/Users/rhenru/Workspace/django/MyDjangoProject/lib/python2.6/plat-mac/lib-scriptpackages', '/Users/rhenru/Workspace/django/MyDjangoProject/Extras/lib/python', '/Users/rhenru/Workspace/django/MyDjangoProject/lib/python2.6/lib-tk', '/Users/rhenru/Workspace/django/MyDjangoProject/lib/python2.6/lib-old', '/Users/rhenru/Workspace/django/MyDjangoProject/lib/python2.6/lib-dynload', '/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6', '/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-darwin', '/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-tk', '/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac', '/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac/lib-scriptpackages', '/Users/rhenru/Workspace/django/MyDjangoProject/lib/python2.6/site-packages', '/Library/Python/2.6/site-packages', '/Library/Python/2.6/site-packages/PIL', '/Library/Python/2.6/site-packages/setuptools-0.6c11-py2.6.egg-info', '/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python', '/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/PyObjC', '/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/wx-2.8-mac-unicode']

How are you installing MySQL-Python? I just tested in a fresh virtualenv and pip install mysql-python seems to have done the trick.
UPDATE:
pip is sort of like a package manager for Python packages.
By default, pip installs to your current site-packages directory, which is on your $PYTHONPATH. This lets other libraries/applications (like Django) access it. pip also works well with virtualenv (it should; Ian Bicking wrote them both), which is a nifty library that lets you sandbox an application. This is nice because it means you can try out new things without polluting (or even needing write access to) the global site-packages directory.
It probably seems like yak-shaving right now, but I'd say it's worth the effort to get up to speed on pip and virtualenv (you may also want to look into virtualenvwrapper, but we'll skip that for now; it's just sugar for virtualenv). It will lead to a slightly more complicated deployment scenario than putting everything in the global site-packages, but for development it's really no harder, and there are lots of good guides to deploying using a virtualenv.
I'd recommend something like the following:
curl -0 http://python-distribute.org/distribute_setup.py
python distribute_setup.py
easy_install pip
pip install virtualenv
virtualenv --distribute MyDjangoProject --no-site-packages
cd MyDjangoProject
source bin/activate (this activates the sandbox that virtualenv created)
pip install django mysql-python
At this point, you should have a totally functional Django+MySQL install (if I missed any steps, just comment and I'll try to add it in). You can start your Django project like this: django-admin.py startproject MyDjangoProject. cd into your project's directory, edit your settings.py file to point to your MySQL database, and run the dev server to test it out like so: ./manage.py runserver (you may need to chmod u+x your manage.py file). Voila! You should be able to access your site on localhost:8000. When you're done working on the project, you can just use deactivate to exit the virtualenv sandbox.
Try not to hold all this against Django: a lot of it is just best practices stuff for working with Python libraries. You could get by with a lot less, but this way it's more reproducible and you're less likely to accidentally mess up one of this project's dependencies when working on a different project.

I had this problem and it turned out to be due to an errant configuration:
export VERSIONER_PYTHON_PREFER_32_BIT=yes
I can't recall what I had this enabled for (some package that required 32-bit), probably related to Google AppEngine. But Setting it to 'no' solved by issues.
Otherwise I just installed everything using homebrew and pip.