Steuercodes (Escape) über serielle Schnittstelle lesen ...

Question

Ich habe hier ein etwas umfangreicheres Problem, daß ich in mehrere Postings aufteilen möchte:

ich bin keinITler, sondern Hobby-Programmierer . Die IT-Abteilung meines  Krankenhauses läst mich leider mit einem Dokumentationsproblem komplett im regen stehen.

Daher habe ich auf die Schnelle eine Anwendung programmiert, die Barcodes über die serielle Schnittstelle liest ( so ein Handscanner) und in eine Datenbank schreibt.

Erstmal zum Scannen:

Grob funktioniert das Scannen bereits problemlos; der Scanner liefert einen 25-35Byte langen String mit den Daten, swoeit okay.

Es handelt sich um GS1 Databar -Codes.

Auf dem Aufkleber stehen genau diese Daten auch drauf, aber anders aufbereitet. Recherchen haben bereits ergeben, daß der GS1-Code verschiedene Felder beinhaltet, jeweils mit einem Präfix und den Daten.

Auf dem Etikett sieht das z.B. so aus: [phone](21)08154711. Da würde einen herstellercode (Präfix 01) von 123456 bedeuten und eine Seriennummer (Präfix21) 08154711. Soweit ganz einfach. Die Datenfleder sind aber nun unterschiedlich lang, z.B. kann der herstellercode 8-13 zeichen haben

Ich bekomme aber nun folgenden String vom Scanner: 011234562108154711, d.h. die Klammern fehlen.

Durch googeln habe ich außerdem erfahren, daß wohl zur Feldtrennung Steuerzeichen FNC (hier ASCII 29) eingestreut sind.

Leider liefert mein Scanner, respektive die serielle Schnittstelle genau diese Steuerzeichen nicht mit.

Warum? Muß ich an der SerialPort-Komponente irgendwas bestimmtes einstellen, damit auch die Steuercodes kommen?

Muß der Scanner speziell programmiert werden ? ich benutze derzeit einen einfachen "Manhattan"-Scanner. ich bin mit Sicherheit nicht der erste, der diese Codes einlesen will.

Vielleicht gibt es ja auch eine raffinierte Methode, den Gesamtcode per Software in die einzelnen Felder zu unterteilen.

Answer 1

Hallo,

bist Du sicher, dass die Steuerzeichen nicht übertragen werden?  Das kann man überprüfen, wenn die empfangene Bytes in der Hexadezimalformat ausgegeben werden.

Der Barcode-Scanner kann man über eine Reihe von Konfiguration-Barcodes konfigurieren. Der Scanner wird im Konfiguarationsmodus versetzt und die Konfiguration-Barcodes werden gelesen. Die Konfiguratin-Barcodes sind normalerweise im Handbuch von Barcode Scanner aufgelistet.

Grüße

Answer 2

Da bin ich mir eben nicht so sicher.

Ich habe die übetragenen Zeichen schon per HEXCode listen lassen, da ist zumindest kein nenicht-druckbares Zeichen bei.

Es gibt im Grunde 2 Stellen, die das unterdrücken könnten:

1. Der Scanner - den habe ich hoffentlich korrekt eingestellt. Wobei ich keine explizite Einstellung für das Übertragen oder Unterdrücken von ESCAPE-Codes gefunden habe.

2. Die Serial.Port-Komponente meiner Software (VB.NET). Könnte das was mit dem Encoding zu tun haben ?

Answer 3

Wie werden die Daten in Serial.Port gelesen? Ich würde die Daten byteweise lesen. Zum Beispiel   mit Read(..) Methode.   

Answer 4

Hier kommt der Code zum Lesen des Barcodes ...
 Private Sub SerialPort1_DataReceived(sender As Object, e As SerialDataReceivedEventArgs) Handles SerialPort1.DataReceived
        recv_str = recv_str + SerialPort1.ReadExisting

        If recv_str.EndsWith(vbCrLf) = False Then
            Exit Sub
        End If

        ' vollstädnigen Barcode empfangen ...

        'Barcode analysieren
        xxx_short = recv_str.Remove(recv_str.IndexOf(vbCrLf))
        recv_str = ""

        ' auswerten
        backgroundworker1.RunWorkerAsync()
    End Sub

Answer 5

Ich habe eben noch ein PDF gefunden, daß wesentlich mehr Programmieroptionen bietet und habe dort auch was gefunden.

Sowohl für Code 128 als auch GS1 und seine Unterarten wird die Möglichkeit angeboten 

"Transmit Application ID " und "Transmit Symbology ID" oder "Enable Code 128 Group Separators".

Leider kein relevanter Erfolg. Ich habe lediglich erreichen können, daß am Anfang ein Kennbuchstabe für die Art des Barcodes eingefügt wird.

Answer 6

Hallo,

die Daten  werden aus dem Empfangspuffer als String gelesen. Es kann sein, dass die Steuer-Zeichen bei der Konvertierung in  Spring-Zeichenkette verloren gehen.  Wie ich schon geschrieben haben, versuch mal die Daten als Byte-Array zu lesen und dann analysieren, ob die Steuerzeichen mitgeschickt wurden.

Grüße

Answer 7

Danke für die Antwort.

Ich habe inzwischen mal ein terminalprogramm benutzt.

Glaubt man diesem Programm, dann werden tatsächlich NUR die Nutzdaten übetragen, keine nicht druckbaren Steuerzeichen.

Dann wird es wohl ein Problem des Scanners sein.

Es sei denn , man kann über den Handshake XON/XOFF (habe ich noch nie gebraucht) irgendwas ändern.

Answer 8

Hallo Nico,

Xon/Xoff steuert das Handshake und ändern nichts an der Übertragung ausgenommen, dass die genau beiden Steuerzeichen (DC1/17, DC3/19)  interpretiert (ausgefiltert) werden.

Auch ein Terminalprogramm müsste "richtig" konfiguriert werden, um Steuercodes auszugeben, denn die meisten Zeichensätze können Codes < 32 (Hex 20) nicht direkt ausgeben.

Bevor Du aufgibst, lies bitte die Daten roh via ReadByte und nicht über eine der String-Methoden (wie ReadExisting, ReadChar) ein. Letztere interpretieren ggf. schon die Daten und entfernen Steuerzeichen.

Werden keine Trennzeichen ausgegeben, so wirst Du die Daten selbst interpretieren können. Was zuverlässig nur sein wird, wenn der Aufbau der Daten in den Anteilen fix ist.

Gruß Elmar

Answer 9

Vielen Dank. Probehalber werde ich das heute abend mal probieren.

BTW: Ich kann beim SerialPort definieren beim wievielten Zeichen ein Ereignis ausgelöst wird. Geht das auch für ein bestimmtes Zeichen (oder Kombination? Ich würde mir wünschen, dass immer ein Eriegnis ausgelöst wird, wenn vbcrlf empfangen würde. Ich habe allerdings bsiher nichts dergelichen gefunden.

.ReadLine müsste ich ja immer aktiv selber auslösen, oder ?

Zum Thema dekodieren: Es sieht so aus, als liessen sich die notwendigen Informationen auch ohne Steuerzeichen extrahieren.

Die Barcodes beginnen mit den Feldern fester Breite. Erst am Ende steht ein variables Feld. Das scheint auch so spezifieziert zU sein.

Answer 10

Hallo,

Xon/XOff steuert den Datenfluss und hat mit dem Datenformat nichts zu tun.

Ein Terminal-Programm konvertiert die Daten auch in einen String und die Steuerzeichen können auch nicht richtig dargestellt werden. Wenn Du ein Terminal-Programm verwenden willst, dann muss das Terminal-Programm so konfiguriert werden, dass die Bytefolge in Hexadezimalformat ausgegeben wird.

Einfacher wäre , wie ich schon geschrieben habe, die Methode Read zu verwenden und dann die Byte-Array zu analysieren.    

Grüße

Answer 11

BTW: Ich kann beim SerialPort definieren beim wievielten Zeichen ein Ereignis ausgelöst wird. Geht das auch für ein bestimmtes Zeichen (oder Kombination? I

Nein. Du kannst die empfangene Bytes-Reihenfolge in DataReceived-Event Methode analysieren und wenn das Telegramm vollständig ist, kann man das Telegram mit eigenem Event weiterleiten.

Grüße