SNAPI DLL einbinden. Scanner MS4407

Hallo Zusammen,
So siehts aus:
Ich habe einen Scanner von Motorola / Symbol MS 4407 der über USB an meinen Rechner angeschlossen ist.
Um ihn anzusteuern giebt eine DLL und ein Beispielprogramm dazu.
Hier der Installer. TXT in EXE umbenennen.

  SNAPISDKv3.00.06.txt (Größe: 5,6 MB / Downloads: 662)

Wer das nicht installieren will, hier mal der Installierte Ordner als ZIP

  SNAPI_SDK.ZIP (Größe: 264,9 KB / Downloads: 557)


Jetzt erst mal noch die Beschreibung des Scanners und den ProgrammerGuid von SNAPI.

  SnapiProgrammersGuide_7137001.pdf (Größe: 1,02 MB / Downloads: 3628)


  7985102a.pdf (Größe: 4,95 MB / Downloads: 2729)


Die DLL hab ich dann importiert. hier die Vis davon.

  SNAPI_ausUserlib.zip (Größe: 315,29 KB / Downloads: 515)


Dann hab ich mir ein Vi gebaut um das mal zu testen.

  Test.vi (Größe: 13,21 KB / Downloads: 366)
snip09

Der Scanner wird richtig getriggert und er scannt auch, leider komm ich bisher nicht an die Gescannten Daten ran.
Wahrscheinlich deshalb weil die Funktion "Set Decode Buffer" speicher allocieren soll und das von LabVIEW aus net geht . ??
Nach dem ich im Forum mal sorumgelesen hab scheint das der fall zu sein.
Stimmt das???

Lösung laut Forum wäre ne Wrapper DLL zu schreiben.

So jetzt mal meine Fragen.
Hat wer zufällig den Scanner schon am laufen?
Stimmen meine vermutungen?
Giebts ne lösung ohne das ich ne Wrapper DLL schreiben muss?
In welcher Sprache schreib ich die am besten?
Hat wer zufällig in VisualC oder VisualBasic einen Einfachen Beispiel Quellcode einer Wrapper DLL für mich?
Oder müßte es sogar gehen und ich hab die Dll falsch eingebunden?

Ich glaub jetzt hab ich alles gefragt, alles hochgeladen und alles geschrieben.


Wer noch mehr infos braucht, einfach bescheid sagen.

Grüße Achimedes

Irgendwas war mit der Test.vi

hab sie neu hochgeladen.

  Test.vi (Größe: 19,8 KB / Downloads: 295)



Sorry

Hi Achim,

leider kenne ich mich nicht damit aus, aber als Mod ist es meine Aufgabe Dich daraf hinzuweisen, immer die VI-Version Deiner hochgeladenen VIs anzugeben, auch wenn der Rest Deiner Frage wirklich löblich ist.

Das ist vom Gefühl her ein Thema für RolfK oder IchSelbst. Die werden Dir sicher weiterhelfen können.

Gruß Markus

Also das Einfachste, wenn man Langzeitunterhalt in LabVIEW und Upgradeability auf neue Treiber-DLLs im Besonderen und Windows Versionen im Allgemeinen und all das mitberücksichtigt, wäre halt schon um eine Wrapper DLL zu machen und dann zumindest aus meiner Sicht in C (Visual C).

Es gibt hier aber einige Möglichkeiten um das mit etwas Gebastel zu umgehen. Zuerst mal wird ein LabVIEW Stringbuffer normalerweise angehalten solange ein Wire irgendwo im Diagram ist, auch wenn dieser Wire effektiv nicht (mehr) verwendet wird, etwa weil er einfach "nur" an ein Sequenzborder geführt ist.

Die Idee wäre also um den Stringwire aus dem Set Decode Buffer wieterzuführen (bis nach dem Disconnect VI um sicherzugehen dass der Buffer garantiert alloziert ist) . Das Ganze ist aber nicht ganz trivial da man jegliche Verzweigung dieses Wires vermeiden muss, da sonst LabVIEW Kopien anlegt und der ursprüngliche Buffer plötzlich nicht mehr gültig sein könnte (und die DLL ins Leere schreibt). Und in Zukunft könnte LabVIEW so schlau werden um auch über Struktur Grenzen zu optimalisieren so dass es erkennt dass der Wire nicht mehr benötigt wird und dann ginge diese Lösung so oder so in die Hose.

Das grössere Problem ist meiner Meinung nach, dass dieses API eigentlich erwartet dass die Applikation eine Windows Message empfangen kann, wo dann der String geliefert wird, sobald der Scan erfolgreich war. Das basiert auf Erfahrungen die ich in anderen Fora gelesen habe, selber habe ich diese Scanner noch nie benützt. Es erscheint mir fraglich, dass man mit erneutem Aufrufen des Set Decode Buffer VIs diesen String auch abfragen kann, aber ich habe mich nicht in die API Dokumentation eingelesen. Wenn es denn Windows Messages erfordert, dann müsste man mit dem auf der NI Site auffindbaren Windows_Message_Queue Example versuchen.

Wenn das alles soweit geklärt ist wäre noch eine andere Methode für die Buffer Allocation für Set Decode Buffer zu evaluieren. Aber bevor nicht sichergestellt ist dass Du den String überhaupt lesen kannst (mit oder ohne Windows Message Queue) hat das wenig Sinn.

' schrieb:Wenn es denn Windows Messages erfordert, dann müsste man mit dem auf der NI Site auffindbaren Windows_Message_Queue Example versuchen.

Laut Scanner-API ist das ganau so:

1-2 Data Returned by DLL schrieb:For example, after a WM_DECODE message is sent to the application, the application should handle the message and process the data in the destination buffer, then call SNAPI_SetDecodeBuffer again.

Also: Message rein machen. Und laut hier soll es auch funktionieren.

Super.
Danke schon mal für eure hilfe.
Werd das mal durchackern und das ergebniss presentieren.


Grüße
Achimedes

Hallo Zusammen,

Ich hab das "windows_messaging_2009.zip" bei NI runtergeladen.

Jetzt giebts da noch ein Problem beim ausfürhren des "Windows Message Queue Example.vi".
Mein PC WinXP Pro SP3, LV2009SP1, = Da bekomm ich ne fehlermeldung
"Fehler6002 ist bei Get Windows ID.vi aufgetreten"
Da wird in der user32.dll die Funktion "FindWindowA" aufgerufen.

Seltsamer weise gehts bei mir zu haus
Win7Pro LV2009SP1
und bei meinem Kolegen
PC WinXP Pro SP3, LV2009SP1
gehts auch.


Hat wer ne Idee was da schief läuft?
oder gleich nen Lösungsvorschlag, der aber nicht sowas beinhaltet wie "Mach die kiste platt";)

' schrieb:Jetzt giebts da noch ein Problem beim ausfürhren des "Windows Message Queue Example.vi".
Mein PC WinXP Pro SP3, LV2009SP1, = Da bekomm ich ne fehlermeldung
"Fehler6002 ist bei Get Windows ID.vi aufgetreten"
Da wird in der user32.dll die Funktion "FindWindowA" aufgerufen.

Das Aufrufen von FindWindowA hat theoretisch ein Problem da das Schwierigkeiten gibt wenn zwei Fenster in Windows genau denselben Titel haben. Das sollte aber keinen Fehler geben, sondern könnte in dem Fall einfach das Handle des verkehrten Fenster zurückgeben, was zumindest problematisch (im Sinne von komischer Funktionsweise) werden könnte wenn dieses zu einer anderen Applikation gehört.

Wenn es sich bei Deinem Fenster um ein LabVIEW VI Frontpanel handelt kannst Du mal versuchen beim ersten Parameter von FindWindowA ebenfalls einen String anzugeben und diesem den Wert "LVDChild" (ohne Anführungszeichen) zu geben.

Hallo RolfK,

Zitat:Das Aufrufen von FindWindowA hat theoretisch ein Problem da das Schwierigkeiten gibt wenn zwei Fenster in Windows genau denselben Titel haben. Das sollte aber keinen Fehler geben, sondern könnte in dem Fall einfach das Handle des verkehrten Fenster zurückgeben, was zumindest problematisch (im Sinne von komischer Funktionsweise) werden könnte wenn dieses zu einer anderen Applikation gehört.

OK

Es ist immer noch nur das "Windows Message Queue Example.vi".
Darum existiert der Fenstername bestimmt nur einmal.

Zitat:Wenn es sich bei Deinem Fenster um ein LabVIEW VI Frontpanel handelt kannst Du mal versuchen beim ersten Parameter von FindWindowA ebenfalls einen String anzugeben und diesem den Wert "LVDChild" (ohne Anführungszeichen) zu geben.

Hab das mal gestestet.
habe das VI "Get Window RefNum.vi" geändert.
Im Knoten "FindWindow" den ersten Parameter "lpszClassName" geändert in String. Da hab ich alle Datenformate ausprobiert (C-String-Zeiger, Pascal-StringZeiger,...) dann noch den Typ "An Typ anpassen" wieder alle datenformate getestet.
Nach änderung des Knotens immer gespeichert und geschlossen damit das auch übernommen wird.
Am Eingang hatte ich immer eine StringKonstante mit eben dem Inhalt "LVDChild"

Hat leider keine kombination irgend was anderes gebracht wie schon die alt bekannte Fehlermeldung.

Danke für den Tipp.
Wenn sich nix mehr ergiebt bis heut Nachmittag, mach ich die Kiste wohl doch mal Platt. (schadet nie )

Hallo Zusammen,

platt machen hat geholfen.^_^
ich kann jetzt normale Messages empfangen.
hier erst mal mein bisheriges ergebniss.

  test1.zip (Größe: 4,94 MB / Downloads: 473)

snip09

Also bisher funktioniert das Triggern des scanners und das auslesen des Speicherbereichs.
Die Bestätigungsmessage bekomm ich noch nicht.

Ich hab mal die "SNAPI Sample Application" gestartet und mit dem Programm "Microsoft Spy++" aus dem "Visual Studio 2008" die WindowsMessages angeschaut.
Da sieht man dann die beiden masseges kommen
<00103> 00050616 P message:0x8006 [User-defined:WM_USER+31750] wParam:0373F6B4 IParam:011824B8
<00104> 00050616 P message:0x8001 [User-defined:WM_USER+31745] wParam:0373F654 IParam:011824B8

Das "P" das da am Anfang nach den vielen Zahlen steht heist wohl "Posted".
Wenn ich dann mein TestVI (mit dem SPY++) beobachte kommt da keine der beiden messages an.

So, da ich nun mal Null Ahnung von dem Windows Messagesystem habe.
Weis wer worann das liegen könnte?

Grüße Achimedes

Sorry für den unschönen code. Ist nur zum testen gedacht ^^