RS232 oder VISA

Das sind Fehler, wie sie typischerweise auftreten: Auf em Kabal get hat ab und zu mal ein Zeichen verlore.

Diese Fehler werden aber von VISA nicht abgefangen! Dafür wäre ein Treiber auf einer höheren Ebene zuständig. An dir liegt es nun, solche Fehler zu erkennen und möglicherweise zu beheben.

Erkennen ist einfach: Alles was nicht ins Format passt, ist ein fehlerhafter Datensatz. Und das Format ist eben festgelegt. Wenn du sagt, /n reicht, dann will ich dem zustimmen: Dann musst du deine Fehlerprüfung aber wie folgt machen: Lies mit VISA-Read den Puffer bis zum Endezeichen /n ein (das kann VISA, guckst du "Trennzeichen"). Jetzt musst du den String testen: vor /n muss eine Zahl im Format (z.B.) +##.## stehen. Du musst das so genau machen. Wie willst du sonst feststellen, dass der Punkt (siehe eines deiner Fehlerbeispiele) verloren gegangen ist? Vor diesem String muss dann ein ';' stehen usw.

Die Frage ist nun, was tun, wenn ein Fehler erkannt worden ist. Ohne ein entsprechend gutes Protokoll kannst du nur eins tun: den Datensatz ersatzlos verwerfen. Kaputte Daten kannst du ohne entsprechende Sicherung nicht reparieren. (In besonderen Fällen kann man anstelle des aktuellen, aber kaputten Datensatzen den vorhergehenden, aber ganzen Datensatz wiederholen als aktuell übernehmen.)

Was du eigenlich brauchst, ist ein fehlertolerantes Protokoll. Normalerweise würde man einen Datensatz mit mehreren Sicherheitsstufen verwenden: STX REP LEN <data> BCC ETX. Außerdem würde man die Datenpackete mit ACK respektive NAK quittieren. Ein solches Protokoll hat zwar den Vorteil, dass dir garantiert keine Datenpakete verloren gehen. Aber es macht halt viel Aufwand. Auf beiden Seiten der Datenübertragung. Wenn du dir diesen vielen Aufwand aber sparen willst, muss du damit Leben, dass ab und zu mal ein Datensatz fehlt.

Auf der anderen Seite: Normalerweise ist es eher unwahrscheinlich, dass ein Zeichen auf dem Kabel kaputt geht. Bei funktionsfähiger Hardware ist die Ausfallrate erfahrungsgemäß höchstens ein Promille. Wenn dir eins von zwanzig kaputt geht, stimtm was mit deiner Hardware nicht.

Anzeige

Zitat:Jetzt musst du den String testen: vor /n muss eine Zahl im Format (z.B.) +##.## stehen

das, woran ich gedacht habe. Ich moechte jede einzelene Zeile pruefen, ob es meine Format entsprecht. Meine Zeile soll so aussehen: [+/-#.##;+/-#.##] und muss 14 Bytes sein. Nun wie kann ich das in LabVIEW formulieren?????

' schrieb:Meine Zeile soll so aussehen: [+/-#.##;+/-#.##] und muss 14 Bytes sein. Nun wie kann ich das in LabVIEW formulieren?????

Nicht formulieren, programmieren!

Mit "Formulieren", also z.B. als Formatstring in einem Scan-Element, bekommst du höchstwahrscheinlich bei diversen Fehlerbildern falsche Ergebnisse. Nur ein successives Scannen des Strings von links nach rechts (oder umgekehrt) wird Erfolg bringen. Und das heißt dann "Programmieren".

Programme für User schreibe ich und andere im Forum aber nur sehr ungerne. Du machst einen Vorschlag und hier im Forum sagt dir einer, warum was nicht so geht.

Du kannst folgendes machen: Zerlege den String in ein Array of Char. Dieses Array gehst du mit einer For-Schleife zeichenweise durch. Indexabhängig machst du eine Case-Sequenz, in der du die einzelnen Chars kontrollieren kannst. Für den 2. Case gibt es ein Element "Ist ASCII-Zahl?". Im ersten Case musst du explizit auf '+' und '-' abfragen. Und so weiter. Wenn alle Cases true ergeben, entspricht der String dem Vorgabeformat.