Huhu DP.

Ich habe ein Progrämmchen, dass alte Protokolldrucker für Industriewaagen ersetzt, und die Protokolle in eine DB umleitet. Die Drucker waren früher via COM angeschlossen, und die Waagen schicken einfache ASCII Zeilen mit diversen Daten. Um diese in der DB besser durchsuchbar zu machen, zerteile ich diese in Ihre Bestandteile (Datum/Uhrzeit, Produktnummer, Charge, Gewicht, etc.). Eingelesen wird dies auf meiner Seite mit TPAPRO's COM-Komponente.
Ich protokolliere auch die eingehenden Rohdaten. Hier drin ist zu erkennen, warum meine Zerstückelung des öfteren bei der Konvertierung von String zu Datum oder Zahl fehlschlägt: Ich bekomme gelegentlich ein "ÿ" (ASCII #255) am Anfang einer Zeile - manchmal sogar 2 davon. Dadurch verschiebt sich meine ganze Auswertung im String, der eigentlich ein Fixed-Field Format hat.
Also statt:

markieren

Code:

17.10.1707:09  63910PROD01                        31.830.000kg--

kommt

markieren

Code:

ÿ17.10.1707:09  63910PROD01                        31.830.000kg--

Aber eben nicht immer, und manchmal 2 mal ÿ.

Klar, ich könnte das einfach durch ein StringReplace() lösen. Aber mich würde dennoch interessieren wo dieses Fragment her kommt, und ob nicht ggf. meine Lese-Methode daran schuld sein könnte. Diese sieht so aus:

zusammenfalten · markieren

Delphi-Quellcode:

procedure TForm1.M1ComTriggerAvail(CP: TObject; Count: Word);
var
  i: Integer;
  c: Char;
begin
  for i := 0 to Count-1 do
  begin
    c := M1COM.GetChar;
    if c=#13 then
    begin
      LogLine(BufM1, 1); // Roh-Zeilen Log in einem Memo
      MakeDBEntry(BufM1, 1, false); // Zerpflücken der Zeile und In DB werfen
      BufM1 := '';
    end
    else
      BufM1 := BufM1 + c;
  end;
end;

Den einzigen Fall, den Du in Deiner Routine konkret behandelst (also auf ein "Drucker" Steuerzeichen reagierst), ist ja offensichtlich Carriage Return.
Das kannst Du natürlich auch für andere Zeichen machen.
Wer sagt denn, dass CR der einzige Fall an Steuerzeichen für diese Protokolldrucker war? Ich war beim ersten Lesen irgendwie auf der Spur COM Schnittstelle, Datenübertragung, fertig. Aber das ist es ja nicht, Du verarbeitest "fertige" Druckerausgaben.
Vielleicht hilft ja ein Blick ins Befehlsregister dieser Drucker ...
Vielleicht ist es auch nur ein Verschlucker des Wägeprogramms, der beim Ausdruck nie aufgefallen ist ...
Wenn Dich der Ursprung interessiert, kannst du diesen Sonderfall ja ebenfalls explizit handhaben und aus dem char(255) eine ganze Logzeile machen. Damit wäre zumindest gleich Dein "Layoutproblem" erledigt und irgendwann ergibt dann die Protokollanalyse vielleicht einen Zusammenhang.

Ja, ich bin bisher davon ausgegangen, dass die Drucker wirklich einfach nur stumpfe "Zeichenspucker" sind, und einfach alles an der Schnittstelle "raus-ASCIIn". Die Drucker gibt es leider schon lange nicht mehr, geschweige denn eine Doku oder eine noch lebende Person die die Modellnamen noch kennt. Aber ich will nicht ausschließen, dass die Waagen sich nicht immer 100% "gefällig" verhalten. Das Zeichen gesondert abfragen ist sogar noch einfacher als ein ReplaceString
Das werde ich erstmal so machen, und die Protokollierung weiter betreiben. Ein Muster hat sich bisher nicht aufspüren lassen. Aber wenn nachher alle Verwiegungen sauber in der DB landen, ist das eigentliche Ziel des Tools ja schon erreicht. Danke dir!

Wennalle anderen Zeichen korrekt sind ist es eher unwahrscheinlich, aber stop/Startbit bautrate etc sind korrekt?

Gruß
K-H

Kann es auch zu Störungen auf der Leitung kommen?
Vielleicht wird ein Startbit erkannt (Störung) und dann wird einfach in Zeitabständen der Eingang eingelesen. Da sich aber nichts ändert (ist ja keine Sendebyte), hast du dann einen konstanten Pegel auf der Leitung, der dann vielleicht #ff ergibt, also alle Bits = 1.
Wäre so etwas denkbar?

Eines meiner ersten Programme war eine Wägeprogramm mit Teilesortierung. Schon lange her. Damals habe ich noch über Printerport die Mechanik angesteuert und ewig mit den Baudraten rumgefriemelt.

Hier sind noch ein paar Verdächtige: Terminal Emulation (-sreste) FF = Bildschirm löschen (Würde man ggF. bei einer besonderen Loginformation erwarten oder wenn der Logger sich verschrieben hat ) oder schlicht unsaubere Verarbeitung von Maskierungsbytes, die dann mit ausgespukt werden. Such mal nach "FF" auf der Seite.
Vielleicht geht gibt es doch einen erkennbaren Zusammenhang:
https://www-user.tu-chemnitz.de/~heh...l/terminal.htm

Bei der Baudrate und den anderen Anschlusseinstellungen bin ich mir recht sicher, dass die passen. Ändere ich dort auch nur einen Parameter, kommt quasi nichts mehr an. Alle anderen Vorschläge klingen für mich jedoch recht plausibel! Zwar würde ich bei einer so stark gestörten Leitung mehr Fehler auch innerhalb der Zeilen vermuten, aber so tief stecke ich nicht in der E-Technik und physikalischen Seite der Signalverarbeitung, als dass ich das abschließend beurteilen könnte.
Wenn $FF von "Terminalprintern" weitgehend ignoriert würde, könnte ich mir schon vorstellen dass man damals dachte: Mh, merkt keiner, lassen wir so. Warum es dann aber nur unregelmäßig kommt... weiß der Geier. Ich habe jetzt auch gemerkt, dass die Dinger ab und zu einfach mal so ein Zeilenvorschub schicken, ohne Log-Zeile und ohne dass was über die Waage gegangen wäre. Gut möglich also, dass da nicht die sorgfältigsten Leute an der Schnittstelle gewerkelt haben damals.

Aber ich filtere diese und das $FF einfach weg, und was in meinen Tabellen steht stimmt mit der Realität überein. Das soll mir (und dem Kunden) genügen. Aber dennoch interessant hier!