![]() |
Nachbildung USB-Commands - Druckversion +- LabVIEWForum.de (https://www.labviewforum.de) +-- Forum: LabVIEW (/Forum-LabVIEW) +--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein) +---- Forum: Datenkommunikation (/Forum-Datenkommunikation) +---- Thema: Nachbildung USB-Commands (/Thread-Nachbildung-USB-Commands) |
Nachbildung USB-Commands - McEarly - 09.01.2011 22:33 Hallo zusammen, ich versuche für mein Roboterprojekt eine Plustek OptiCam M1 über LabView sowohl in beiden Achsen als auch den Fokus zu bewegen. Es gibt leider keinerlei API o.ä. zu der Kamera. Also ist Reverse Engineering angesagt ![]() Durch Mitloggen der USB Kommunikation weiss ich wie die Commands aussehen müssen damit sich die Cam bewegt. Ich bin nur nicht in der Lage diese Commands mit LabView nachzubilden. Irgendwas mache ich falsch. Hier der Screenshot mit den SOLL-Werten, bei denen sich die Cam bewegt: [attachment=31569] Byte 4 0x82 des TransferBuffer gibt die SOLL-Position des Stellmotors an Zur Simulation habe ich das USB RAW vi aus den Beispielen genommen: [attachment=31577] Leider ergibt sich nach der Vi-Ausführung folgende Reaktion auf dem USB Bus: [attachment=31578] Der Bufferinhalt landet irgendwie nicht als TransferBuffer im Protokoll, sondern taucht unter TransferBufferMDL auf. Kann mir jemand sagen, ob ich bei den Werten im VI etwas falsch mache oder ob es andere VIs gibt , die besser geeignet sind? Das muss doch irgendwie gehen. Ich verwende LV2010. Für Hilfe wäre ich sehr dankbar. Oliver Nachbildung USB-Commands - Y-P - 16.01.2011 09:16 Damit fange ich leider wirklich nichts an. Aber hast Du eigentlich schon mal beim Hersteller nachgefragt? ![]() Gruß Markus Nachbildung USB-Commands - snuz - 17.01.2011 09:08 Hallo McEarly, wie schon Y-P geschrieben hat brauchst Du die Informationen vom Hersteller, denn nur der kennt die Kommandos für die Plustek OptiCam. Ich stand vor einiger Zeit auch vor dem Problem ein USB Device auszulesen und kannte die richtigen Parameter nicht, die USB Kommunikation hatte ich auch über einen USB Monitor ausgelesen, aber ohne Erfolg. Die Lösung bei mir lieferte NI mit dem Ereignistyp USB Interrupt "3FFF2037". Bei mir ging es nur darum permanent Werte abzufragen. Falls Du keine Informationen vom Hersteller bekommst und andere Versuche fehlschlagen, könntest Du dir ein Programm schreiben, welche alle möglichen Werte "ausprobiert" und auf Ereignis wartest - wird aber bestimmt über den Weg etwas länger dauern. Gruß snuz |