Hallo Nominas,
Zitat:Aber das bringt mich noch nicht wirklich weiter...
Entweder ich verstehe irgendwas nicht oder ich habe die Problematik nicht gut genug erklärt.
Was ich vorgeschlagen habe, läuft auf das hier hinaus: trenne die Verwaltung der Daten von der Anzeige auf dem Frontpanel!
Damit erreichst du:
- du kannst schnell genug Daten vom seriellen Port lesen
- du kannst die Daten auswerten und in einem Array zwischenspeichern: da dies NICHT auf dem Frontpanel angezeigt wird, ist das auch sehr schnell
- für die eigentliche Anzeige liest du "immer mal wieder" (z.B. 5mal die Sekunde) diesen Zwischenspeicher aus und aktualisierst die Anzeige entsprechend - in einer entkoppelten/parallelen Schleife...
Noch ein Tipp:
Nicht immer muss die Art, wie man Daten zwischenspeichert, exakt die gleiche sein, wie man diese Daten dann auf dem FP darstellt. Auch hier hat man die Möglichkeit, sich jeweils "optimale" Datenstrukturen zu überlegen: siehe meinen Vorschlag zu einem 2D-Array of Cluster of [String, Farbe(n)]…
Zitat:- 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
Ich hoffe, mein Ansatz ist jetzt klarer: der Zwischenpuffer nimmt alle diese Angaben entgegen (Text,Farben).
Über die Indizes der Elemente im 2D-Array kannst du sehr einfach die Koordinaten abbilden.
Und nochmal: dieser Zwischenbuffer (Array of…) ist NICHT die Anzeige auf dem FP!
Zitat:>> 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
Das ist sehr wahrscheinlich nur deshalb zu langsam, weil du jedesmal die Tabelle neu zeichnen willst - was einfach Irrsinn ist!
Niemand ist in der Lage, mit mehr als 24Hz Bilder wahrzunehmen - und Text in einer Daten-Tabelle sinnvoll zu erfassen, benötigt mehr Zeit als das "Ansehen" von Bildern eines Kinofilms…
Zitat:>> Zu den beiden Punkten: Ich bin der Meinung, dass LabVIEW bei jedem Tunnel erstmal eine Kopie der Daten macht. Ist dieser Gedanke schon falsch?
Ja.
Zitat:>> Ich muss ja aus dem String, der evtl. nach einem Befehl kommt ein Array machen, siehe oben. Daher verstehe ich diese Anmerkung nicht...
Schau mal hier:
Die Stringkonstante finde ich einfacher als eine U8-Konstante mit zwei weiteren Funktionen, um exakt den gleichen Wert zu erzeugen…
(Macht dein VI nicht schneller, aber mMn besser lesbar.)
Sowas hier ist ist auch sehr ineffizient:
Wenn nach einer Formatierung noch 20 Zeichen Text kommen, dann wird dieser Text Zeichen für Zeichen einzeln in die Tabelle eingetragen - und die Tabelle für jedes Zeichen einem Update unterzogen!
Warum schickst du den Text nicht mit einmal in die passende Position in der Tabelle!?
Deshalb nochmal mein Vorschlag: trenne die Auswertung und (Zwischen-)Speicherung der Daten von der Darstellung auf dem FP!
/
Verarbeiten von ESC-Sequenzen (VT100)
