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!
(04.12.2012 23:11 )blubblub schrieb: Mich wundert es, dass keine Daten verloren gehen. Es wird eine saubere gerade
Linie im Diagramm gezeichnet. Das versteh ich aber nicht.
Mich nicht.
(04.12.2012 23:11 )blubblub schrieb: Die Erzeugerschleife wird alle 50ms ausgeführt. Dabei versucht sie bei jeder Ausführung
einen neuen Wert in den Puffer zu legen. Wenn bereits 10 Werte drinne sind, und das
dürfte nach 500 ms der Fall sein,
Richtig erkannt!
(04.12.2012 23:11 )blubblub schrieb: dann wird die Erzeugerschleife zwar weiterhin alle 50ms
ausgeführt, aber sie legt keine neuen Daten mehr in den Puffer, da dieser voll ist.
Nach 500 ms müssten die Werte {1, 2, 3, 4, 5, 6, 7, 8, 9, 10} drin sein.
Hier ist dein Denkfehler. Queue ist voll. Lies dir die Hilfe zu Enqueue Element durch. Du hast also Timeout -1 angeschlossen, d.h. die Erzeuger-Schleife wartet jetzt so lange, bis die Verbraucher-Schleife wieder ein Element entnommen hat.
Wenn du mit nicht glaubst, dann leg dir einen Indikator mit dem Schleifen-Index aufs Frontpanel.
Gruß, Jens
P.S.: Noch zu einem deiner früheren Beiträge: Mit mind. 50 Hz unter Windows zu regeln zu wollen, und das noch mit einem Single-Prozessor, das ist schon haarig. Windows ist kein Echtzeit-Betriebssystem und verteilt die Ressourcen nach Gutdünken. Ein Graph-Zeichnen unter LabVIEW ist leider nicht gerade das Schnellste, und kann bei vielen Datenpunkten richtig CPU fressen. Und wenn du Pech hast, dann passiert dir das auch in einer Producer-Consumer-Struktur.
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!
(24.12.2012 10:15 )blubblub schrieb: Ich werd mir noch ein paar Gedanken hierzu machen müssen.
Ja, und das Wichtigste wäre, die Funktionsweise von Queues erst mal richtig zu verstehen.
Der Witz ist nämlich, dass sich Erzeuger- und Verbraucherschleife ohne Wait in der Verbraucherschleife von selbst synchronisieren. Die Wait-Funktion ist bereits in "Element aus Queue entfernen" auf intelligente Art mit eingebaut. Die zusätzliche Einfügung eines Waits in diese Schleife kann, je nach Taktrate das Erzeugers, tödlich sein - überflüssig ist es in jedem Fall.
Ich finde das einfügen einer wait Funktion aus folgendem Grund recht nützlich:
In der Erzeugerschleife muss sichergestellt sein, dass diese spätestens alle 20 ms ausgeführt wird.
Die Verbraucherschleife hingegen kann ruhig 500 ms versetzt aufgerufen werden um dort dann Daten
aus dem Puffer zu lesen und in einem Rutsch mehrere in das Diagramm zu schieben, so dass die Queue
wieder leer ist.
Der Vorteil der 500ms wait Funktion wäre meiner Meinung nach, dass die Erzeugerschleife die volle
Aufmerksamkeit von meinen beiden CPU Kernen erhält. Die Erzeugerschleife müsste sich also nur hin und wieder mal
die CPU Kerne mit den Systemprozessen von Windows teilen.
Zudem ist ja das Zeichnen von Diagrammen so CPU lastig, dass ich mir denke alle 500ms reicht aus.
Da während eines gesamten Versuchs eh nicht mehr als 3 MB an Daten erzeugt werden und ich 1 GB Arbeitsspeicher
zur Verfügung habe, wird die Queue eh nie so vollaufen, dass mir das Programmabstürzt.
Im schlimmsten Fall hätte die Queue dann im Arbeitsspeicher 3 MB gepuffert bevor sie in der Verbraucherschleife
angefangen werden im Diagramm zu verwerten.
Momentan hab ich ja das Problem, dass wenn ich Daten in einer Schleife von der Messkarte lese
und sie in derselben Schleife direkt in das Diagramm schreibe, ich die 20ms maximale
Schleifendurchlaufzeit manchmal nicht einhalten kann. Dadurch regelt die angeschlossene Maschine
falsch, da Werte zu später eingelesen werden. Dieses Problem muss irgendwie mit dem Zeichnen
des Diagramms zusammenhängen. Denn wenn das Diagramm nicht mitgezeichnet wird, sondern die
Werte lediglich direkt in eine Datei geschrieben werden, kann man sehen dass alle Werte
korrekt erfasst wurden. Sobald das Diagramm mitzeichnet kommt es aber zum Reglerproblem,
da die Schleife manchmal länger als 20ms für einen Durchlauf braucht und Werte dadurch zu spät erfasst werden.
Hier bestätigt sich, wichtig die Befolgung des Rates gewesen wäre, die Funktionsweise von Queues erst mal verstehen zu lernen.
Das vorgeschlagene Warten in der Empfangsschleife hört sich gut an - nur hast Du dabei die Eigenschaften der Queue nicht beachtet. Bei Aufruf von "Element aus Queue entfernen" wird nicht etwa die Queue geleert, sondern ledigich ein einziges Element entfernt. Wenn also der Erzeugern alls 20 ms einen neuen Wert in die Queue schmeisst, und die Empfangsseite nur alle 500ms einen Wert abholt, sind zunehmender Zeitverzug und schließlicher Pufferüberlauf vorprogrammiert.
Falls Du wirklich Probleme hast mit Ausführungszeit und zu hoher CPU-Auslastung, dann bestimmt nicht dadurch, dass alle 20ms ein einzelner Datenpunkt abgeholt und dargestellt wird. Die kritische Stelle liegt vermutlich wo ganz anders, aber dazu müsste man das genze Programm kennen.
@Lucki: aus eigener Erfahrung, das Neu-Zeichnen eines Graphen (vor allem wenn er mal viele Datenpunkte enthält und am besten/schlimmsten auch noch Autoskalierung der Achsen aktiviert ist) ist leider bei LabVIEW ein zeitintensiver Prozess. Alle 20 ms (also mit 50 Hz) einen Graphen zu aktualisieren kann wirklich alle anderen Prozesse gnadenlos ausbremsen.
@blubbub: Wie lange dauert dein Versuch? Du schreibst selber, dass da nicht viele Daten zusammenkommen. Wenn dir also die Graph-Anzeige die Steuerung/Regelung zerstört, dann musst du mglw. auf diese "Live-Anzeige" verzichten und erst am Ende alles anzeigen.
Außerdem musst du in der Verbraucherschleife (wenn sie langsamer läuft - durchaus ein erstrebenswertes Ziel) die Queue immer komplett leeren, und nicht nur ein Element auslesen. Das geht z.B. mit dem VI "Flush Queue".
Gruß, Jens
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!
(27.12.2012 14:27 )jg schrieb: @Lucki: aus eigener Erfahrung, das Neu-Zeichnen eines Graphen (vor allem wenn er mal viele Datenpunkte enthält und am besten/schlimmsten auch noch Autoskalierung der Achsen aktiviert ist) ist leider bei LabVIEW ein zeitintensiver Prozess. Alle 20 ms (also mit 50 Hz) einen Graphen zu aktualisieren kann wirklich alle anderen Prozesse gnadenlos ausbremsen.
Es geht hier ganz konkret um das Signalverlaufsdiagramm. Solche Erfahrungen hatte ich früher auch gemacht, aber ab irgendeiner Version von LV scheint sich das grundlegend geändert zu haben. Da gibt es das Problem nur noch im Modus "Synchrone Anzeige", was aber nicht der Normalmodus ist. Aber auch da braucht es wesentlich weniger als 20 ms für ein Update.
Beispielzeiten für 1 Updating in beigefügtem Programm:
Normal: 0.2 us
Synchrone Anzeige: 0.6 ms
Mein Prozessor: AMD-CPU mit integrierter Gaphik. Die Graphik habe ich so gelassen wir sie aus der Bibliothek kommt. Natürlich wird man im Modus Synrchone Anzeige mit um so längeren Zeiten rechnen müssen, je größer die Graphik ist. Ganz katastrophal ist aber das Drüberlegen, z.B einer Zahlenanzeige, über das Plotfeld.
Mir ist die Sache mit rasend schnellen Updaterate selbst nicht ganz geheuer, zumal man mit so einer Aussage gewissermassen den Rest der Welt gegen sich hat. Deshalb wären Beispiele interessant, die vielleicht etwas anderes belegen. Aber bitte nicht in Form ausgeklügelter Kopfgeburten, sondern als ausführbares VI. (Anm.: Diesen Absatz habe ich in der Formulierung geändert)
Da muss ich widersprechen. Mit Historienlänge 10k und drei Plots statt einem ändert sich an dem Ergebnis praktisch nichts: Jetzt 0.3us statt 0.2 us.
Das war ja auch zu erwarten: Der graphische Teil das Updatings wird von der Messung in diesem VI überhaupt nicht erfasst. Das ist ein anderer Thread mit niedrigerer Priorität als das Einlesen der Daten in den Speicher der Graphik.
Das Testbeispiel ist aber deshalb nicht praxisfremd - höchstens in dem unrealistischen Fall, dass das Vi bereits ohne die Graphik schon 100% CPU-Last beansprucht und nirgendwo eine Wartezeit im Programm ist, in der LV das graphische Updating erledigen könnte.
Und wenn aber dann die Gelegenhait da ist: Dann werden alle bis dahin angefallenen, noch nicht graphisch dargestellten Messwerte mit eine Ratsch upgedatet. Es wird auf dem Schirm trotz vieler neuer Daten nur ein einziges Bild erneuert - das geht schnell uund ist von der Zeitdauer her unabhängig von der Anzahl neuer Daten.
