LabVIEWForum.de - ext. DLL - Einbindung Read Funktion

Hallo Forum,

dafür das ich noch keine Erfahrungen mit der Einbindung von externen DLLs in LV habe, bin ich dank dem Tutorial https://www.labviewforum.de/Thread-DLL-einbindung schon weit gekommen.

Anwendung: Es geht um ein RFID Lesegerät welches einen RFID-Transponder (Q5 - ASCII) ausliest.
[attachment=57241]

Status: Eine Verbindung zu dem RFID Lesegerät via USB konnte ich bereits erfolgreich aufbauen.
[attachment=57242]

Problem: Ich bekomme nicht den Inhalt (Block1: ABCD) vom RFID-Transponder ausgelesen.

Denke es liegt an der falschen Verwendung der Read Funktion? Da ich aufgrund fehlender C++ Erfahrung überhaupt nicht im Stande bin die Beschreibung der Funktion zu verstehen.
[attachment=57245]

Letztlich liegt mir alles (siehe Link zur SDK: dll, Beschreibung, C++ Beispiele) vor, leider bin ich aber aktuell nicht in der Lage das fachlich umzusetzen. Huh

Support: Kann mir jemand anhand der vorhandenen Daten ggf. unter die Arme greifen? Und mir einen Tipp geben warum ich nicht den Inhalt "ABCD" ausgelesen bekomme?
[attachment=57244]

Link zur SDK: http://www.gis-net.de/rfid/deutsch/softw...ickler.htm

(25.01.2017 12:33 )TobSTAR schrieb: [ -> ]Kann mir jemand anhand der vorhandenen Daten ggf. unter die Arme greifen? Und mir einen Tipp geben warum ich nicht den Inhalt "ABCD" ausgelesen bekomme?

Funktioniert das Lesen des Strings "Serial" (aus GetUSBDeviceNames) und der Strings "pDevVer out" und "pDevName out" (aus DeviceVersion) richtig?

Was sagt denn der Error-Cluster nach jedem DLL-Knoten?

Welchen Wert haben denn die Werte "Buflen" und "result" des Knotens "RawRead"?

(25.01.2017 22:35 )IchSelbst schrieb: [ -> ]Funktioniert das Lesen des Strings "Serial" (aus GetUSBDeviceNames) und der Strings "pDevVer out" und "pDevName out" (aus DeviceVersion) richtig?

Jepp (siehe auch ScreenShot Status aus Nachricht 1), da steht 11362367 drin.

(25.01.2017 22:35 )IchSelbst schrieb: [ -> ]Was sagt denn der Error-Cluster nach jedem DLL-Knoten?

Alles i.O. keine Fehler/ Warnungen oder der Gleichen.

(25.01.2017 22:35 )IchSelbst schrieb: [ -> ]Welchen Wert haben denn die Werte "Buflen" und "result" des Knotens "RawRead"?

BufLen (Buffer-Länge): steht das drin was ich vorne rein gebe
rtRawRead (return): 16
[attachment=57251]

(27.01.2017 08:15 )TobSTAR schrieb: [ -> ]rtRawRead (return): 16

Hast du in der Dokumentation nachgelesen, was der Rückgabewert 16 bedeutet? Wenn ja, was bedeutet er?

Bekommst du eine AV beim beenden des VIs oder der IDE?

Du solltest anstelle eines leeren Strings mal einen String der Mindestlänge BufLen probieren.

Ein paar Hinweise:

1) Du spezifizierst überall ein Bufferlänge von 8194 Bytes für die Stringbuffer obwohl du daneben auch noch jeweils einen Parameter übergibts wieviele Bytes der jeweilige Buffer maximal empfangen kann. Ändere diese Zahl in den Variablennamen der entsprechenden Längenvariablen. Zwar ist 8194 immer grösser dann die Zahl die Du dann effektiv als Länge angibst, also passiert so kein Crash, ABER!!!! wenn Du das immer so machst gehst Du irgendwann mal bei einer Funktion mit der Länge spielen und vergisst den Buffer auch länger zu machen und Kabumm, krachts. Zudem ist das schwerwiegende Speicherverschwendung wenn Du überall einen Buffer von 8194 Bytes übergibst aber die Funktion nur 16 davon verwenden darf!

2) Der Rückgabewert der ReadRaw Funktion liefert gemäss Dokumentation -1 zurück im Fehlerfall und 0 oder eine positivie Zahl die angibt wieviele Bytes effektiv in den Buffer geschrieben wurden.

3) Da diese Funktion Rawdaten zurückgibt kann auch ein Nullwert im Buffer vorkommen. Da Du diesen Wert als Stringtyp definiert hast, der als C Stringpointer übergeben wird, kontrolliert LabVIEW nach der Rückkehr der Funktion ob der Buffer ein Nullbyte enthält und kürzt den String bis vor dieses Nullbyte. Das ist korrekt den Du hast angegeben, dass es ein C Stringpointer ist und bei C Strings wird halt einfach der Characterwert hinter dem letzten gültigen Character auf NULL gesetzt. Um das zu verhindern machst Du daraus ein Bytearray und übergibst das als C Array Pointer an die Funktion. Da Arrays durchaus 0 als Wert enthalten dürfen macht LabVIEW hier keinen Scan nach der Zürückkehr und lässt Dir den Buffer in der Länge die Du am Eingang angegeben hast.

4) Last but not least kann der Buffer natürlich weniger Bytes enthalten dann die Büfferlänge die Du angegeben hast, Hier verwendet man dann ein Array Subset mit der Länge die die Funktion als Rückgabewert zurückgegeben hat, aber nur wenn dieser Wert grösser ist dann -1, ansonsten hat die Funktion einen Fehler gehabt und solltest Du saubere Fehlerbehandlung durchführen. Nach dem Array Subset verwendest Du noch ein Byte Array zu String wenn Du unbedingt willst und dann kannst Du Dir den RawBytebuffer doch noch als String betrachten, aber eigentlich ist das wahrscheinlich irreführend, raw Bytes sind normalerweise keine Strings.

Und nein gemäss C Syntax besteht absolut kein Unterschied zwischen einem ANSI C Stringpointer und einem Byte Arraypointer. Aber gemäss uralter C Konvention benützen halt alle Stringfunktionen dieses Nullbyte, währenddem Arrayfunktionen typischerweise immer einen expliziten Längenparameter notwendig machen.

Besten Dank an IchSelbst und rolfk für den Support. Ich muss die gegebenen Hinweise erstmal sacken lassen Dry

Sobald ich das verstanden und durchgearbeitet habe melde ich mich wieder.

Mal wieder besten Danke für die ganzen Hinweise, ich bin einen riesen Schritt weiter gekommen. Ich schaffe es jetzt in der Tat den RFID-Transponder auszulesen. Dance2

[attachment=57291]

(31.01.2017 00:38 )rolfk schrieb: [ -> ]1) Du spezifizierst überall ein Bufferlänge von 8194 Bytes für die Stringbuffer obwohl du daneben auch noch jeweils einen Parameter übergibts wieviele Bytes der jeweilige Buffer maximal empfangen kann.

Die Spezifikation wurde wohl über den Import der DLL automatisch vorgenommen? Kann mich nicht erinnern da etwas spezifiziert zu haben???

(31.01.2017 00:38 )rolfk schrieb: [ -> ]Ändere diese Zahl in den Variablennamen der entsprechenden Längenvariablen.

Wahrscheinlich So oder:
[attachment=57289]

(31.01.2017 00:38 )rolfk schrieb: [ -> ]Um das zu verhindern machst Du daraus ein Bytearray und übergibst das als C Array Pointer an die Funktion. Da Arrays durchaus 0 als Wert enthalten dürfen macht LabVIEW hier keinen Scan nach der Zürückkehr und lässt Dir den Buffer in der Länge die Du am Eingang angegeben hast.

Wahrscheinlich So oder:
[attachment=57290]

Gerne nochmal kurzes Feedback sollte ich einen der Hinweise falsch verstanden/ umgesetzt haben.

Im Anhang das korrigierte VI (noch ohne Fehlerbehandlung), sollte jemand mal vor dem selben Problem stehen.

(07.02.2017 13:59 )TobSTAR schrieb: [ -> ]Gerne nochmal kurzes Feedback sollte ich einen der Hinweise falsch verstanden/ umgesetzt haben.

Ich habe das VI selber jetzt nicht nochmals heruntergeladen um im Detail anzuschauen, aber die Bildausschnitte die Du im Post hast sehen soweit korrekt aus.