Zugang zu USB über Python

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Benutzeravatar
Toni83
User
Beiträge: 125
Registriert: Donnerstag 28. Juli 2005, 10:53

Zugang zu USB über Python

Beitragvon Toni83 » Freitag 31. März 2006, 20:15

Hallo,

Ich möchte gerne Daten die über USB in meinen PC gelangen mit Python auslesen. Leider ist dies nicht so einfach wie erhofft. Ich habe schon PyUSB installiert, hat aber nicht funktioniert. Auch mit LibUSB hat PyUSB nichts ausgegeben.
Ich bin nun ziemlich ratlos. Gibt es noch andere Tools für Python, damit ich die Daten die über die Datenleitung gelangen auslesen kann?

Gruss,
Toni
modelnine
User
Beiträge: 670
Registriert: Sonntag 15. Januar 2006, 18:42
Wohnort: Celle
Kontaktdaten:

Beitragvon modelnine » Freitag 31. März 2006, 22:51

Das was Du als "Daten auslesen" beschreibst ist extrem allgemein gefasst. Willst Du selber Pakete generieren, und Dich als Anbieter mit einem USB-Endgerät selbst verständigen, oder willst Du zuhören wenn zwei andere reden, oder was genau willst Du machen?

Je nachdem hängts nämlich ein bissel davon ab ob PyUSB Dir helfen kann oder nicht: PyUSB kann Dich nur als Anbieter mit einem Gerät das irgendwo anders ist alleine reden lassen (dafür sorgen die jeweiligen USB-Treiber im Kernel), Du hast sozusagen exklusives Recht auf ein Gerät. Wenn Du mithören willst, kommst Du um Kernel-Patches nicht drum rum, da Du dann im Endeffekt eine der Aufgaben von USB aushebeln willst, die vom Kernel so nicht an den Userspace weitergegeben wird.
--- Heiko.
Benutzeravatar
Toni83
User
Beiträge: 125
Registriert: Donnerstag 28. Juli 2005, 10:53

Beitragvon Toni83 » Samstag 1. April 2006, 12:13

Hallo Heiko,

Danke für deine Antwort. Es ist anscheinend doch nicht so einfach wie mit pyserial bzw. pyparallel.
Übers USB Interface hängt an meinem Rechner ein Gerät, dass mit IC2 und SPI Geräten kommunizieren kann.
( http://sine.ni.com/nips/cds/view/p/lang/en/nid/202367). Das sind z.B. Geräte wie z.B. Drehgeber oder Lineargeber. Diese Geräte werden mit der Versorgungsspannung aus dem USB Interface versorgt. Diese Spannung wird dann z.B. bei den Lineargebern auf den maximalen Verfahrweg 14-bitig aufgeteilt. Je nachdem welcher Verfahrweg zurückgelegt wurde gibt der Lineargeber bei einem bestimmten Verfahrweg eine bestimmte 14-bitige Zahl an die Kommunikationseinheit zurück.
Diese 14-bitige Zahl wird über das USB-Interface übertragen. Nun möchte ich allerdings mit Python diese Zahl herauslesen um die genaue Position des Lineargebers zu bestimmen.
Ich habe noch nicht soviel mit Python & USB zu tun gehabt, weshalb ich etwas Probelem habe.

Gruss,
Toni
Benutzeravatar
Toni83
User
Beiträge: 125
Registriert: Donnerstag 28. Juli 2005, 10:53

Beitragvon Toni83 » Dienstag 4. April 2006, 17:59

Servus,

habe mein Problem inzwischen selbst gelöst. Nach einer aufwendigen Suche ist es mir doch gelungen, ein Paket für Python zu finden, wo es möglich ist mit Geräten die z.B. an GPIB-, USB- und RS232 Schnittstellen hängen zu kommunizieren.
PyUSB funktioniert anscheinend nur, wenn das angehängte Gerät über einen FTDI Chip verfügt. Hat nun mal nicht jedes Gerät.
PyVISA (steht für Python Virtual Instrument Software Architecture ) eignet sich hervorragend für Messgeräte, die z.B. an einem USB-Gerät hängen und die man aus Python heraus ansprechen möchte (z.B. Messwerte in Python einlesen, ...). Ich habe speziell ein USB-Gerät von National Instruments, das ich aus Python heraus ansteuern möchte. Das Gerät kommt erst im Laufe der Woche, sodass sich auch PyVISA sich erst mal beweisen muss. Ich werde dann auf jeden Fall noch antworten, ob es geklappt hat.
An dieser Stelle geht schonmal ein großes Dankeschön an Herrn Torsten Bronger. :D

Gruss,
Toni
Benutzeravatar
Toni83
User
Beiträge: 125
Registriert: Donnerstag 28. Juli 2005, 10:53

Beitragvon Toni83 » Donnerstag 6. April 2006, 15:29

Habe inzwischen die Karte von National Instruments erhalten...
Leider war VISA nicht dabei. Die Anschaffung von VISA ist dann doch noch mit zusätzlichen Kosten verbunden.
Stattdessen war die Software NI-DAQ dabei. Für diese Sotware gibt es auch eine Python Extension. Leider ist diese aber für Python 2.2, auf dem Rechner habe ich aber Python 2.3. Wie kann ich diese Extension trotzdem auf meine neuere Version von Python benutzen? (Ni-DAQ für Python lässt sich nur installieren, wenn Python 2.2 auf dem Rechner vorhanden ist.)
Gibt es was besonderes zu beachten?

Gruss,
Toni
modelnine
User
Beiträge: 670
Registriert: Sonntag 15. Januar 2006, 18:42
Wohnort: Celle
Kontaktdaten:

Beitragvon modelnine » Donnerstag 6. April 2006, 15:51

Ja, Du wirst sie wahrscheinlich gar nicht nutzen können, weil das Binär-API sich bei Python relativ regelmäßig verschiebt, so dass die Erweiterung zwar noch quellkompatibel (gedankt sei's Makros... :-)) sein dürfte, aber eben nicht binärkompatibel. Das wäre aber auszuprobieren, und ich weiß momentan nicht inwiefern 2.2->2.3 eine so massive Änderung des ABIs war dass es nicht mehr tut, obwohl in 2.3 eine ganze Menge mit der echten class/type-Unification auch unter der Haube passiert ist.

Unter Windows (wovon ich jetzt mal ausgehe, weil sie als Binary ausgeliefert wird) kommt erschwerend hinzu dass die Extension aufgrund von dem besch... System wie die libc zur Verfügung gestellt wird mit mehr oder weniger dem selben Compiler und Linker gebaut sein muß wie dein Python-Binary selbst; das ist aber bei 2.2->2.3 definitiv nicht gegeben, da gabs auf jeden Fall einen Umstieg bei dem C-Compiler (glaub sogar eine neue Hauptversion von MSVC++, die dann mit neuer C-Runtime einhergeht, und zwei C-Runtimes verschiedener Versionen, eine für Python, eine für das Modul, in einem Prozess gehen eben nicht). Aber auch das wäre auszuprobieren, indem Du die DLL einfach mal in dein site-packages-Verzeichnis packst und testest.

Falls eine der obigen Probleme auftritt ist das beste was Du machen kannst dem Anbieter schreiben und entweder Quellen für das Modul anfordern und selbst kompilieren, oder sogar nach Dokumentation das Binding neu schreiben (was der schwierige Weg ist), oder einfach 2.2 installieren und damit glücklich sein (was der bei weitem einfachere Weg ist). 2.2 findest Du auf dem offiziellen Python-Server auf jeden Fall noch zum installieren; so aus der Welt ist das noch nicht.

Andere Wege wären noch, mittels zum Beispiel IronPython ein .NET-Binding (was es ja mit Sicherheit auch gibt, weil .NET ist ja das tollste ;-)) zu benutzen, oder mittels Jython ein Java-Binding. Aber bevor ich damit Anfangen würde, würd ich erst mal probieren über den Anbieter was aktuelleres zu bekommen, oder gucken ob sich jemand anderes die Mühe gemacht hat da was aktuelleres zu schreiben.
--- Heiko.
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Beitragvon Leonidas » Donnerstag 6. April 2006, 16:54

modelnine hat geschrieben:Unter Windows (wovon ich jetzt mal ausgehe, weil sie als Binary ausgeliefert wird) kommt erschwerend hinzu dass die Extension aufgrund von dem besch... System wie die libc zur Verfügung gestellt wird mit mehr oder weniger dem selben Compiler und Linker gebaut sein muß wie dein Python-Binary selbst; das ist aber bei 2.2->2.3 definitiv nicht gegeben, da gabs auf jeden Fall einen Umstieg bei dem C-Compiler (glaub sogar eine neue Hauptversion von MSVC++, die dann mit neuer C-Runtime einhergeht, und zwei C-Runtimes verschiedener Versionen, eine für Python, eine für das Modul, in einem Prozess gehen eben nicht).

Naja, das muss nicht sein. Denn Python 2.3.x für Windows wurde mit Visual C++ 6 kompiliert, 2.4.x mit VIsual C++ 7.1 (aka 2003). Beide Versionen haben sich gut mit meinen mit MinGW kompilierten Modulen verstanden, ohne dass ich so viel beachten musste. gcc ist ganz einfach toll.

modelnine hat geschrieben:Falls eine der obigen Probleme auftritt ist das beste was Du machen kannst dem Anbieter schreiben und entweder Quellen für das Modul anfordern und selbst kompilieren

Ich würde es ja selbst kompilieren, aber es braucht die libnidaq32 und libnidex32, die es warscheinlich kostenlos nicht geben wird, oder?
My god, it's full of CARs! | Leonidasvoice vs Modvoice
modelnine
User
Beiträge: 670
Registriert: Sonntag 15. Januar 2006, 18:42
Wohnort: Celle
Kontaktdaten:

Beitragvon modelnine » Donnerstag 6. April 2006, 17:30

Beide Versionen haben sich gut mit meinen mit MinGW kompilierten Modulen verstanden, ohne dass ich so viel beachten musste. gcc ist ganz einfach toll.


Das dürfte eher daran liegen dass Deine MinGW-kompilierten Module die entsprechende C-Runtime genutzt haben für die das Python kompiliert wurde, weil Du's mit der entsprechenden python.lib gelinkt hast (bzw. distutils das automatisch macht). Probier mal ein Erweiterungsmodul mit VC++6 zu kompilieren, und es in einer Umgebung von VC++7.1 einzusetzen, und *päng*.

Ich würde es ja selbst kompilieren, aber es braucht die libnidaq32 und libnidex32, die es warscheinlich kostenlos nicht geben wird, oder?


Ich hab keine Ahnung... Frag den Anbieter, würde mir da nur so ganz spontan einfallen; zur Not kann man wenn das DLLs sind auch ein bissel Reverse-Engineering machen; ich kann mir kaum vorstellen dass die statisch in das Python-Modul gelinkt sind.
--- Heiko.
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Beitragvon Leonidas » Donnerstag 6. April 2006, 17:36

modelnine hat geschrieben:Ich hab keine Ahnung... Frag den Anbieter, würde mir da nur so ganz spontan einfallen; zur Not kann man wenn das DLLs sind auch ein bissel Reverse-Engineering machen; ich kann mir kaum vorstellen dass die statisch in das Python-Modul gelinkt sind.

Das ist mir persönlich den Aufwand nicht wert, habe ja nichts davon.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Benutzeravatar
Toni83
User
Beiträge: 125
Registriert: Donnerstag 28. Juli 2005, 10:53

Beitragvon Toni83 » Donnerstag 6. April 2006, 20:16

Danke für die Antworten.
Ich habe jetzt den Source gefunden, habe aber Probleme diesen in Python einzubinden.
Im zip-File enthalten ( http://sourceforge.net/project/showfile ... p_id=82407 ):

nidaq.i
nidaq.py
PKG-INFO
setup.py

Wenn ich die setup.py öffne, steht folgendes drin:


Code: Alles auswählen

from distutils.core import setup, Extension

setup(name='nidaq', version='1.0',
      py_modules = [ 'nidaq' ],
      ext_modules = [Extension('_nidaq',
                               ['nidaq.i'],
                               include_dirs=['.',
                                          "D:/Programme/National Instruments/NI-DAQ/DAQmx ANSI C Dev/include"],
                               library_dirs=[r"D:\Programme\National Instruments\NI-DAQ\DAQmx ANSI C Dev\lib"],
                               libraries=['nidaq32', 'nidex32'])])


Daraus sehe ich, dass beim durchlaufen von setup.py, die Installation von NI-DAQ notwendig ist, damit er auf die Ordner include und lib zugreifen kann. Das habe ich auch gemacht nur kommt im cmd die Ausgabe:

usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
or: setup.py --help [cmd1 cmd2 ...]
or: setup.py --help-commands
or: setup.py cmd --help

error: no commands supplied
Drücken Sie eine beliebige Taste . . .

Was ist den jetzt? Welche "commands" werden benötigt?
Mir fehlt echt der Durchblick. Vielleicht beschäftige ich mich auch schon zu lang damit, dass ich dies nicht sehe...
modelnine
User
Beiträge: 670
Registriert: Sonntag 15. Januar 2006, 18:42
Wohnort: Celle
Kontaktdaten:

Beitragvon modelnine » Freitag 7. April 2006, 00:13

Probier:

Code: Alles auswählen

python setup.py build


gefolgt von einem

Code: Alles auswählen

python setup.py install
--- Heiko.
Benutzeravatar
Toni83
User
Beiträge: 125
Registriert: Donnerstag 28. Juli 2005, 10:53

Beitragvon Toni83 » Freitag 7. April 2006, 11:13

Danke für die Antwort. Die Ausgabe ist schon eine andere, leider funktioniert das ganze immer noch nicht:

D:\Python23>python setup.py build
running build
running build_py
creating build\lib.win32-2.3
copying nidaq.py -> build\lib.win32-2.3
running build_ext
error: Python was built with version 6 of Visual Studio, and extensions need to
be built with the same version of the compiler, but it isn't installed.

Das gleiche macht dieser beim Installieren:

D:\Python23>python setup.py install
running install
running build
running build_py
running build_ext
error: Python was built with version 6 of Visual Studio, and extensions need to
be built with the same version of the compiler, but it isn't installed.


Muss ich jetzt noch Visual Studio installieren? Oder gibt es da einen anderen Ausweg?
Wenn es keine andere Möglichkeit gibt außer Visual Studio zu installieren, wie wäre das weitere Vorgehen? Reicht einfach die Installation, oder muss ich dann noch etwas beachten?

Gruss,
Toni
modelnine
User
Beiträge: 670
Registriert: Sonntag 15. Januar 2006, 18:42
Wohnort: Celle
Kontaktdaten:

Beitragvon modelnine » Freitag 7. April 2006, 12:53

error: Python was built with version 6 of Visual Studio, and extensions need to
be built with the same version of the compiler, but it isn't installed.


Diese Fehlermeldung sagt alles. Du mußt VS6 installieren, und erst dann kannst Du das Python-Modul installieren. Beachte vor allen Dingen die Ausgabe, das ist genau das was ich bereits mehrfach gesagt habe, dass ein Extension-Modul mit der selben VC++-Version gebaut werden muß wie Python selbst auch, aufgrund der Abhängigkeit von der msvcrt.dll (also der C-Lib unter Windows).

Du brauchst, da in dem Paket eine .i-Datei ist, auch noch SWIG zum erstellen einer C-Datei aus den Quellen; wie das ganze unter Windows genau eingebunden wird: keine Ahnung.

Ich würd einfach "Trial and Error" sagen... :-)
--- Heiko.
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Beitragvon Leonidas » Freitag 7. April 2006, 13:22

modelnine hat geschrieben:Diese Fehlermeldung sagt alles. Du mußt VS6 installieren, und erst dann kannst Du das Python-Modul installieren. Beachte vor allen Dingen die Ausgabe, das ist genau das was ich bereits mehrfach gesagt habe, dass ein Extension-Modul mit der selben VC++-Version gebaut werden muß wie Python selbst auch, aufgrund der Abhängigkeit von der msvcrt.dll (also der C-Lib unter Windows).

Oder eben MinGW benutzen, der auch mit VC++ zurechtkommt. Allerdings kann es dann Probleme mit den Libs geben, denn MinGW hat manchmal mit denen Probleme.

modelnine hat geschrieben:Du brauchst, da in dem Paket eine .i-Datei ist, auch noch SWIG zum erstellen einer C-Datei aus den Quellen; wie das ganze unter Windows genau eingebunden wird: keine Ahnung.

Wenn SWIG im %PATH% ist, dann findet distutils die afair von selbst. Was das angeht, würde ich auch empfehlen, eine vorkompilierte SWIG-Version zu nehmen, das spart unnötige Arbeit.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Benutzeravatar
Toni83
User
Beiträge: 125
Registriert: Donnerstag 28. Juli 2005, 10:53

Beitragvon Toni83 » Freitag 7. April 2006, 20:02

Danke. Werde versuchen nun Visual Studio zu installieren.
Werde auch das sog. "SWIG" heute noch installieren.
Was bedeutet eigentlich:

Das SWIG muss im %PATH% sein, damit die distutils die afair findet?

Gruss,
Toni

Wer ist online?

Mitglieder in diesem Forum: StareDog