Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
zunächst freue ich mich endlich einen Grund gefunden zu haben, in diesem Forum einzusteigen.
Zurzeit arbeite ich an einem relativ komplexen LV-Projekt (LV 2011, DE), bei dem die Darstellung von aufgezeicheneten Daten in Echtzeit eine große Rolle spielt. Da es ziemlich bequem ist, Graphen aus "Programm 1" mit Daten Aus "Programm 2" über Referenzen und Eigenschaftsknoten (Werte) zu beschreiben, habe ich dieses Verfahren "gnadenlos" in meiner Software implementiert.
Heute habe ich festgestellt, dass die Darstellung die Echtzeitanforderungen bei weitem nicht erfüllt. Bei der Suche nach dem Grund habe ich das im Anhang eingefügte Testprogramm zusammengeklickt.
Aus den Ergebnissen des Programms schließe ich, dass das Beschreiben der Graphen über Eigenschaftsknoten eine relativ hohe Zeitverzögerung verursacht (im Vergleich zum direkten Beschreiben).
Sollte sich jemand finden, der mir die genaue Ursache eines solchen Verhaltens von LabVIEW erklären kann, wäre ich echt glücklich um in Zukunft nicht mehr die Hälfte eines fast fertigen Projektes ändern zu müssen.
Noch Glücklicher wäre ich natürlich, wenn jemand weiß, wie man mit Referenzen und/oder Eigenschaftsknoten arbeitet, ohne so viel Rechenzeit zu verbraten.
(08.12.2011 21:49 )gentos schrieb: Sollte sich jemand finden, der mir die genaue Ursache eines solchen Verhaltens von LabVIEW erklären kann, wäre ich echt glücklich um in Zukunft nicht mehr die Hälfte eines fast fertigen Projektes ändern zu müssen.
Setzen von Werten über Eigenschaftsknoten, überhaupt die Verwendung von Eigenschaftsknoten, war schon immer "langsam" in LabVIEW.
Hintergrund:
1) Eigenschaftsknoten werden zwingend im User-Interface-Thread abgearbeitet.
2) Jede Veränderung per Eigenschaftsknoten erzwingt ein Frontpanel-Update!
Bei Setzen einer Variable per Terminal oder lokaler Variablen ist dagegen das FP-Update nicht sofort zwingend.
Bei Schreiben von vielen Werten in einen Graphen fällt dies besonders stark auf, da ja noch das gesamte Rendering der Plot-Linie hinzukommt.
Gruß, Jens
P.S.: Darstellung eines Graphen in "Echtzeit", das ist auch so eine Sache. Ein heute üblicher TFT-Monitor hat eine Wiederholfrequenz von 60 Hz. Das ist nicht viel.
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
nutze einen i5 für die Software, sollte also Deinem i3 in nichts nachstehen. Kannst Du eventuell deinen Code dazu veröfentlichen?
Etwas mehr zum Projekt:
Die Frontpanels mit den Graphen werden im ersten Schritt geladen und zwar soviele wie der User braucht. Das heißt die VI's
mit den Graphen sind nicht im running mode sondern nur geladen. Somit kann ich sie nicht über eine Queue beschreben, sondern ausschließlich über die Referenzen.
@jg:
Vielen Dank für die Aufklärung. Man lernt nie aus! wie ich sehe.
09.12.2011, 08:48 (Dieser Beitrag wurde zuletzt bearbeitet: 09.12.2011 08:51 von Lucki.)
Die Ergebnisse Deiner 3 Tests sind plausibel und mit "an Sicherheit grenzender Wahrscheinlichkeit" richtig, aber ganz sicher eben nicht, weil ein methodischer Fehler drin ist. Sie werden nämlich parallel, d.h gleichzeitig ausgeführt. Um ganz wasserdicht zu sein, solltest Du z.B. im ersten Test eine boolsche Konstante erzeugen und herausführen, durch den zweiten Test hindurchschleifen und an den dritten Test anschließen. Oder die drei Tests in eine Sequenz mit 3 Cases packen. Oder... usw.
Leider bist Du an einen chronischen Nörgeler geraten, denn mit gefällt das Test-VI immer noch nicht. Der Unterschied zwischen 2 und 3 darf einfach nicht sein, es handelt sich doch um das Gleiche. Es kann z.B sein, daß der Graphikchip mit 2 noch nicht fertig ist, während 3 schon abgearbeitet wird. D.h. bei Änderung der Test-Reihenfolge würde es ganz anders aussehen. Noch bessere wären Pausen zwischen den Tests, aber dann brauchte man mehr Uhren und mehr Cases - zu viel Mühe.
Auf alle Fälle empfielt es sich, jeden Test in eine For-Schleife zu packen und die Zeit zu mitteln. dann ist es genauer.
Habe das unten mal gemacht.
Auf Grund einschlägiger Erfahrung habe ich mir seit Langem diese Faustregel zurechtgelegt:
Lokale Variable: Unwesentlich länger als direkt
Globale Variable: 2 Mal länger als direkt
Eigenschaftsknoten Wert: 100 mal länger als direkt.
Besten Dank für Deinen Beitrag und Dein Beispielprogramm.
Ich bin mir sicher, dass es manchen dabei helfen wird, Zeitabschätzungen für den Einsatz der einzelnen Möglichkeiten (Property/lokale Variable/globale Variable) zu machen und Zeitverluste an zeitkritischen Programmstellen zu vermeinden.
Der Zeitunterschied in meinem Beispielrogramm zwischen Schritt 2 und Schritt 3 ist nicht immer gegeben (so alle 10 Mal ist er da). Ich denke es hängt davon ab (wie Du auch sagst), ob Schritt 2 wirklich verarbeitet wurde.
Lösung für mich:
Ich bin bereits dabei mein Projekt umzustrukturieren, sodass ich die Graphen direkt beschreibe.
Thema:
Meine Fragen sind somit geklärt. Vielen Dank an alle Beteiligten
(09.12.2011 07:57 )gentos schrieb: .. Kannst Du eventuell deinen Code dazu veröfentlichen?
..
Ich habe das nachprogrammiert, was Du in dem Bild in Deiner Frage gezeigt hattest. In einer Schleife habe ich eine lokale Variable statt der Referenz mit Eigenschaftsknoten verwendet.
(09.12.2011 07:57 )gentos schrieb: .. Kannst Du eventuell deinen Code dazu veröfentlichen?
..
Ich habe das nachprogrammiert, was Du in dem Bild in Deiner Frage gezeigt hattest. In einer Schleife habe ich eine lokale Variable statt der Referenz mit Eigenschaftsknoten verwendet.
Wie Lucki bereits gepostet hat führt eine lokale Variable kaum zu einer Zeitverzögerung gegenüber dem direkten Beschreiben. Die Referenz benötigt dagegen so etwa das 100-fache an Zeit...
Damit steht fest, dass das Beschreiben von Graphen über Referenzen keine besonders gute Wahl ist.
In meinem Projekt nehme ich mit 51.200 kSamples/s abgetastete Signale auf und muss sie in bestimmten Blocklängen in den Graphen schreiben. Bei einer Blocklänge von 1024 Samples, muss sich der Graph alle 0,02 s (20 ms) aktualisieren. Wenn ich aber allein für das schreiben eines Blocks 80 ms benötige und das ganze in z.B 10 Graphen schreiben will (parallele Verarbeitung projektbedingt nich möglich), dann liege ich zeitlich bei 800 ms pro Block und verpasse somit 800ms / 20ms = 40 Blöcke á 1024 Werte.
zu den 60 Hz Bildwiederholfrequenz des Monitors, die du angesprochen hast:
bei 60 Hz habe ich eine zeitliche Auflösung von 1/(60Hz) = 0,016 s (= 16ms) und bin somit mit meinen 20ms immer noch in dem Bereich wo mein Monitor die Änderung auflösen kann. Das menschliche Auge kann es auch!
Zum Projekt:
habe mein Projekt nun umstrukturiert und beschreibe die Graphen direkt. Die Beschreibung samt Signalanalysen kostet jetzt keine 2ms mehr.
Die dazu parallel ablaufenden Funktionen zur Skalierung der Graphengrößen bei Fenstergrößenänderung scheint keine auswirkung auf die Berarbeitungsdauer zu haben (obwohl sie über Referenzen läuft).
/
Graph über Eigenschaftsknoten beschreiben
