Verschiedene Werte beim Auslesen eines NFC-Tags

  • Hallo Gemeinde


    Wenn ich einen NFC-Tag an den NFC-Leser halte bei geöffnetem Editor, liest er folgendes aus:

    36046403873762845 (Seriennummer des NFC-Tag)

    Lese ich den gleichen NFC-Tag mittels Keyproc aus (d.h. ich starte die keyproc.exe und lege den NFC-Tag auf den Leser), kommt dies als Rückgabe:

    2147483647

    Hat jemand eine Idee woher der Unterschied kommt?


    Einmal editiert, zuletzt von SOLVE-SMART (22. Februar 2024 um 21:00)

  • Dein Problem ist die Nutzung des ExitCodes als Rueckgabewert, wofuer das nicht ausgelegt ist.

    Der ExitCode ist ein Integer. Dein String mit der eingelesenen Nummer wird also von AutoIt automatisch in ein Integer konvertiert. Der maximale Wert fuer ein Integer ist 2147483647... schaut bekannt aus? Deine Zahl ist viel groesser als der maximale Integer Wert, also macht AutoIt aus der umwandlung das beste, was es kann und gibt den hoechstmoeglichen Wert aus.

    Du solltest ein ConsoleWrite($g_sAusweisNr&@crlf) machen, bevor du das Programm mit (Exit) verlaesst. Dann wird der String ausgegeben, den du eingelesen hast.

  • Hallo Aspirinjunkie und Kanashius,


    vielen lieben Dank für eure Denkanstöße. Sie haben mir geholfen


    Ich habe nun den folgenden Code eingefügt, wenn das Enter-Zeichen kommt:

    Damit funktioniert die Ausgabe wie sie soll.


    Hintergrund: Die S/N der NFC-Tags unterscheiden sich nur in den letzten 6 Stellen.

    Wenn die Nummer also länger wie 6 Stellen ist, werden die überzähligen ersten 11 Stellen abgeschnitten.

    Ist die ausgelesene Nummer 6 Stellen lang(z.B. durch manuelle Eingabe der Personalnummer) wird diese ausgegeben.

    Damit ist der Thread gelöst. Nochmals vielen lieben Dank an euch :thumbup::thumbup::thumbup:

    Einmal editiert, zuletzt von SOLVE-SMART (22. Februar 2024 um 21:01)

  • Hallo Gemeinde,
    Hallo Aspirinjunkie und Kanashius,

    ich habe einen neuen Leser. Dieser liest nun die Seriennummer der Tags im Hexformat ein. Also so: 1D70536A031080
    ich habe also den Code umgebaut und schneide nun die hinteren 8 Stellen weg und habe die Map um die Buchstaben
    A - F erweitert. Trotzdem erkennt die IF -Abfrage in Zeile 69 die Buchstaben nicht und gibt den Fehlercode 815 zurück.

    Hätte jemand eine Idee warum?


    Wenn ich die If-Abfrage von Zeile 69 auskommentiere funktioniert alles!

    Einmal editiert, zuletzt von hipfzwirgel (23. Februar 2024 um 10:36)

  • Trotzdem erkennt die IF -Abfrage in Zeile 69 die Buchstaben nicht und gibt den Fehlercode 815 zurück.

    Was gibt Fehlercode 815 zurück?
    MapExists?
    Hast du die Stelle mal debuggt, indem du die Inhalte der Variablen ausgeben lässt?

    Ansonsten kann ich selbst nicht viel testen, da ich kein NFC-Reader habe.
    Wenn du ein Minimalbeispiel baust, welches den Fehler reproduziert und auch so bei anderen lauffähig ist (z.B. den Wert im Programm direkt verwenden anstatt über NFC-Device auslesen), dann kann man dir wahrscheinlich eher weiterhelfen.

  • Ich hab das ganze mal etwas uebersichtlicher umstrukturiert. Jetzt musst du eigentlich nur noch die _processInput und _exitWithNumber aendern.

    Ich bin mir nur komplett unsicher, wann du was bei den Zahlen abschneiden willst...

    Bei der Dezimalzahl wolltest du die letzten 6 Zahlen... Bei der Hexadezimalen schreibweise auf einmal die ersten 8??? Das macht keinen Sinn. Ich hab die Umwandlung von Hexadezimal zu Dezimal implementiert, was genau damit passieren soll musst du wissen^^
    Wenn du selbst experimentieren willst kannst du die ConsoleWrite Zeilen in den Funktionen auskommentieren, dann solltest du jedesmal sehen, was genau eingelesen wird und was daraus gemacht wird.

    Du solltest auch echt ueberdenken, die Zahl mit dem ExitCode zurueck zu geben... der ist eigentlich nur dafuer da, Fehlercodes zurueckzugeben... Fuer so etwas schreibt man normal mit ConsoleWrite in den STDOUT, der von anderen Programmen weiterverarbeitet werden kann und dadurch auch komplexere Daten zurueckgeben kann. Gleichzeitig ist das Ergebnis dann auch in der Konsole zu lesen.

    Ich hoffe, das hilft dir weiter.

    LG, Kanashius

  • @ Aspirinjunkie:

    Die Funktion Keyproc gibt den Code 815 zurück wenn in der ausgelesenen Nummer ein Buchstabe auftauchen sollte,
    da in der Map nur Zahlen und die Entertaste hinterlegt waren. Ich habe die MAP um die Werte A - F(virtual Keycodes für Buchstgaben A - F)
    erweitert aber das scheint nicht zu funktionieren. Was auch die Frage ist warum:?:

    :Glaskugel: Ich vermute die HexZahlen A - F entsprechen nicht den virtuellen Keycodes der Buchstaben A - F...


    @ Kanshius:

    Das Abschneiden liegt daran, was von den NFC-Lesern eingelesen wird. Der alte Leser hat die S/N des NFC-Tags warum auch immer, in eine dezimale Zahl umgewandelt und ausgegeben.
    Der neue Leser gibt die S/N der Tags als original Hex-Zahl aus. Die eingelesenen Zahlen unterscheiden sich im ersten Fall(obsolet) in den letzten 6 stellen und im zweiten Fall(aktuell) in den ersten sechs Stellen.

    Die Rückgabe als Exitcode kam daher, dass ich die Keyproc-Funktion eigentlich für ein anderes Program entworfen hatte, und dort war sie zunächst eine interne Funktion die die Werte einfach als Return zurück gegeben hatte. Die Werte waren explizit eine sechs-stellige Zifferfolge. Nur als interne Funktion hatte das aufgrund von Änderungen im Windows-OS nicht mehr funktioniert und ich habe sie daraufhin als Exe ausgegliedert. Da war der Exitcode in der Keyproc in dieser Form notwendig, da die Reaktionen, bzw. das Error-Handling des Original-Programmes eben auf Exit-codes basierten.
    Ich hätte sonst das ganze Programm umschreiben müssen. ;)

    Dein Script Beispiel werde ich die Tage testen und Feedback geben.

  • Moin,

    AutoIt
    Global $sHex = "1D70536A031080"
    Global $sRev = ""
    Global $iPos = 14 - 1
    While $iPos > 0
    	$sRev &= StringMid($sHex, $iPos, 2)
    	$iPos -= 2
    Wend
    Global $iSNR = Dec($sRev, 2)
    MsgBox(0, "SN", "Hex: " & $sHex & @LF & "Rev: " & $sRev & @LF & "Dez: " & $iSNR)

    ?

  • Hallo Velted,

    ich danke dir für deinen Beitrag, allerdings weiß ich nicht so recht was du damit zum Ausdruck bringen wolltest?

    Die S/N wird korrwekt ausgelesen. Die Frage ist:

    Warum werden die Hex-Zahlen A - F nicht zugelassen obwohl die Map dahingehend erweitert wurde?

  • Ich wiederhole mich mal:

    Hast du die Stelle mal debuggt, indem du die Inhalte der Variablen ausgeben lässt?


    Ansonsten sind die zugeordneten Codes 1:1 die entsprechenden ASCII-Codes.
    Anstatt einer extra Map sollte hier auch ein Chr($tKEYHOOKS.vkCode) ausreichend sein.
    Aber wie gesagt: dazu muss $tKEYHOOKS.vkCode auch tatsächlich das enthalten was du erwartest.
    Das sollte man halt zum Debugging prüfen.
    Dann sollte aber auch die Map-Variante funktionieren.

    Daher zum letzten mal: Debugge und lass dir die relevanten Variableninhalte samt ihrem Datentyp ausgeben.

  • Hallo Aspirinjunkie,

    so ich habe mal die die Variable debuggt. folgendes Ergebnis:


  • Hallole,

    ganz offensichtlich funktioniert das mit den Virtual Keycodes nicht.
    Debugge ich die Variable $tKEYHOOKS.vkCode bei Eingabe via Tastatur gibt er, wenn ich das große D eingebe und
    beim kleinen D Zeichen 68 was eigentlich numerische Taste 8 ist. Bei E ist es Zeichen 69 sehr seltsam...

  • wenn ich das große D eingebe und beim kleinen D Zeichen 68 was eigentlich numerische Taste 8 ist. Bei E ist es Zeichen 69 sehr seltsam...

    Ich verstehe noch nicht was daran seltsam sein soll.
    68 ist der ASCII-Code vom großen D und 69 ist der ASCII-Code vom großen E.
    Also in Hex-Darstellung 0x44 und 0x45.
    Und so hast du es ja auch in deine Map eingetragen (auch wenn wie gesagt ein Chr() wohl reichen würde).

  • Hallo Aspirinjunkie,

    alles klar. Da war ich aber mal total falsch gelegen. Ich dachte da kommt die Hex-Zahl des virtuellen Keycodes zurück. Den ASCII-Code hatte ich da gar nicht auf dem Schirm! :whistling::rolleyes: Oh mann....
    Danke für den Hinweis.
    Der Chr() reicht sicherlich. Wie gesagt ich hatte die Keyproc für ein Buchungssystem entwickelt wo explizit eine
    Prüfung erfolgen musste welche Zeichen eingegeben wurden. Buchstaben sind dort nämlich per se tabu...

    @ Velted: beim Abbruch stand immer die Zahl 1 in der Variable drin. Da er beim D bereits ausgestiegen ist.

    Ich glaube wir können das Thema nun als erledigt betrachten, da das Problem ja ohnehin schon gelöst ist.

  • Moin hipfzwirgel,

    @ Velted: beim Abbruch stand immer die Zahl 1 in der Variable drin. Da er beim D bereits ausgestiegen ist.

    Ich habe nach dem Inhalt der Variablen $tKEYHOOKS.vkCode gefragt. Ich glaube nicht, dass die mit Inhalt 1 zum Abbruch führt. Aber ...

    Ich glaube wir können das Thema nun als erledigt betrachten, da das Problem ja ohnehin schon gelöst ist.

    Danke für die Info.