Vielen Dank für eure Mühe!
Aber das bringt mich noch nicht wirklich weiter...
Entweder ich verstehe irgendwas nicht oder ich habe die Problematik nicht gut genug erklärt.
Da ich am Ersten nichts ändern kann, probiere ich es mit dem Zweiten.
Das µC-System sendet mir den Aufbau einer Anzeige. Einmal die komplette Seite mit Texten, danach nur bestimmte Werte und Status-Meldungen.
Seite: \1B[2J\1B[1;70f13.12.2022\1B[7m\1B[2;10fMesswert-Uebersicht\1B[0m\1B[5;5fTemperatur\s1\s-\sxx.x\s\B0C\r\n\s\s\s\sTemperatur\s2\s-\sxx.x\s\B0C\1B[5;30fDruck\s\s\s\s\s\s1\s-\sxxxx\smbar\1B[6;30fDruck\s\s\s\s\s\s2\s-\sxxxx\smbar\1B[10;5f\1B[0mKein\sFehler
Werte: \1B[5;20f12.3\1B[6;20f21.5\1B[5;45f\s123\1B[6;45f2345\1B[10;5f\1B[7mFehler\s0815\1B[0m
Nach meinem Verständnis muss man dann alle Elemente (
ESC-Sequenzen) durchgehen und schauen, was zu tun ist.
Dafür bilde ich ein Array, anhand von \1B (=ESC), prüfe, ob das Element einen bekannten String enthält und führe den jeweiligen Befehl aus.
[2J = Anzeige löschen
[1;70f13.12.2022 = gehe an Zeile 1, Spalte 70 und schreibe ab dort die Zeichen 13.12.2022
[7m = ab jetzt soll die Anzeige invertiert erfolgen (hier könnte auch direkt Text folgen)
[2;10fMesswert-Uebersicht = gehe an Zeile 2, Spalte 10 und schreibe ab dort die Zeichen Messwert-Uebersicht
[0m = ab jetzt soll die Anzeige normal sein
[5;5fTemperatur 1 - xx.x °C\r\n Temperatur 2 - xx.x °C = wie oben, aber hier sind auch noch CarriageReturn \r und LineFeed \n dabei, die entsprechend interpretiert werden müssen.
Damit man das nachvollziehen kann, habe ich das vi "VT100-Beispiel" angehängt. Mit dem Button "Fehler" kann man die Anzeige eines Fehlers, in invertierter Anzeige, simulieren.
Nach meinem Verständnis ergeben sich daraus folgende Eckpunkte:
- Man muss diese Tabelle nehmen, denn die Befehle können an beliebige Koordinaten springen. Z.B. bei den Messwerten. Bei einem 2D-Array habe ich nicht die Formatierung einzelner Zellen.
- Man muss die Anzeige-Texte Zeichen für Zeichen interpretieren, denn bei CR oder LF muss kein Zeichen dargestellt, sondern die aktuelle Koordinate geändert werden
- Man muss sich merken, welche Formatierungs- oder Anzeige-Vorgaben gerade gelten, denn die können beim nächsten Mal an derselben Stelle anders sein
(In meiner aktuellen Anwendung habe ich natürlich viel mehr Text bzw. Befehle.)
Zu euren Vorschlägen und Anregungen
1.- Den seriellen Port so schnell wie möglich bedienen. (Tipp: verzichte nach Möglichkeit auf BytesAtPort, siehe auch hier.) und 2. Daten in einen Zwischenbuffer packen: es bietet sich eine Queue an.
>> Wenn ich das Lesen des Ports und die Auswertung in zwei Schleifen mit Queue aufteile ist die Auswertung doch immer noch zu langsam, nur dass sich die Strings in der Queue sammeln
3. Daten auswerten und in eine Repräsentation umsortieren, die sich für die Table-Anzeige anbietet.
>> Da ich ja glaube, dass ich in jedes zu bearbeitende Feld gehen muss, um Inhalt und Formatierung zu setzen, weiß ich nicht, wie das aussehen könnte...
4a. Und jetzt der wichtigste Punkt: die Table nicht "andauernd" neu zeichnen, sondern nur 5-10× pro Sekunde!
>> Mit einer realistischen Menge Inhalt, dauert das Parsen so lange, dass "gefühlt" nur einmal pro Sekunde aktualisiert wird...
4b. Und die Table natürlich nicht in der gleichen Schleife updaten, in der du die serielle Schnittstelle bedienen willst!
>> Check
- Wozu also jedes mal jede Zelle einzeln aktualisieren. Aktualisiere alle Zellen der Tabelle zunächst mit schwarz auf Weiß und dann änderst du nur noch die Zellen, welche davon abweichen.
>> Da die Formatierung bei jeder Aktualisierung anders sein kann, siehe Fehler, muss ich das doch jedes mal aktualisieren.
- Die Texte zunächst in ein Array schreiben (du kennst die Größe des Arrays) und dann nicht per PropertyNode schreiben, sondern direkt mit dem Terminal verbinden.
>> Dann müsste ich einmal die Inhalte und dann noch die Formatierung durchgehen. Da sehe ich den Vorteil nicht.
- Das Parsen der Escape-Sequenzen optimieren.
>> Das ist eigentlich meine Ausgangsfrage. Vielleicht wird es mit dem Beispiel und der obigen Beschreibung deutlicher, aber ich selber sehe halt keine bessere Möglichkeit.
Andere Anmerkungen:
- FP-Elemente, die mit dem ConnPane verbunden sind, sollten nicht in irgendwelchen Strukturen versteckt werden. (Beispiel: Anzeige-Referenz und "read buffer" im subVI.)
- Die Panel-Referenz muss man nicht in jeder Iteration erneut auslesen, das kann man einmal vor der Schleife erledigen.
>> Zu den beiden Punkten: Ich bin der Meinung, dass LabVIEW bei jedem Tunnel erstmal eine Kopie der Daten macht. Ist dieser Gedanke schon falsch?
>> Denn deshalb habe ich gedacht, dass ich die FP-Elemente in den NoError-Case schiebe, dann spare ich eine Daten-Kopie und im Error-Case werden sie definitiv nicht benötigt.
>> Und mit dem Gedanken habe ich auch die Panel-Referenz in der Schleife...
- In der Case-Struktur, in der du die Befehle für dein VT100 erstellt: man kann natürlich aus einem U8 ein Array of U8 bauen und das dann in einen String wandeln. Man kann aber auch eine String-Konstante in \-Code- (oder Hex-)-Anzeige verwenden und einfach den gewünschten Wert eintippen…
>> Ich muss ja aus dem String, der evtl. nach einem Befehl kommt ein Array machen, siehe oben. Daher verstehe ich diese Anmerkung nicht...
- Zu Punkt 2: du liest anscheinend "nur" Text und Farbinformationen aus. Damit könntest du den Zwischenbuffer als 2D-Array of strings und 2D-Array of color(s) (oder als 2D-Array of cluster[string color(s)] ) organisieren…
>> Da das Lesen vom seriellen Port schnell genug geht, könnte man das in der Schleife aufteilen. Aber ich kann mir grad nicht vorstellen, wie ich die Koordinaten handhaben soll...
>> Außerdem gibt es ja noch andere Befehle, bzw. dann CSI-Sequenzen. In meiner Anwendung mindestens noch "2J" für das Löschen der Anzeige.
>> Und für anderen µC-Elektroniken könnte man das ja ergänzen.
Es tut mir leid, vielleicht hätte ich die Aufgabe von Anfang an ausführlicher erklären sollen.
Aber wenn man sich länger mit einem Thema beschäftig, glaubt man gerne, dass das ja jedem klar ist...
Nochmals vielen Dank für eure Zeit!
Gruß
Nominas
/
Verarbeiten von ESC-Sequenzen (VT100)
