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!
Hallo zusammen und vielen lieben Dank, so komme ich tatsächlich auf meine gewünschten 5000 Werte.
Ich werde mir die Kritik zu Herzen nehmen und das nächste Mal direkt ein VI hochladen.
Allerdings läuft die Darstellung sehr ruckartig und mit kurzen Verzögerungen ab, was mich auch nicht wundert, bei "Datenpaketen" von 50 Werten. Kann man diesen Schönheitsfehler noch beheben? Nach meinem Verständnis müsste es besser werden, wenn ich 5000 Schleifenwiederholungen und 1 sample per channel einstelle. Es wird aber dann nicht besser.
Anzeige
06.04.2016, 12:19 (Dieser Beitrag wurde zuletzt bearbeitet: 06.04.2016 12:39 von Lucki.)
Natürlich geht das, warum probierst Du das nicht gleich selbst aus? Allerdings bringt es nichts, alle Werte einzeln zu lesen. Das menschliche Auge merkt ab Bildwiederholraten von ca. 50/s kein Ruckeln mehr, und viele häufiger updated auch der Monitor nicht. Um das Ruckeln weg zu bekommen, genügt es also, die Update-Rate auf ca. 50 Hz zu erhöhen. Also statt 100 Paketen zu je 50 Werten 500 Pakete zu 10 Werten aus dem Datenpuffer lesen.
Danke Lucki, für die ausführliche Erklärung. Ich habe das auch ausprobiert, kann aber bei verschiedenen Einstellungen kaum einen Unterschied feststellen. Daher habe ich nochmal nachgefragt. Ich werde dann aber mal weiter rumprobieren
06.04.2016, 14:28 (Dieser Beitrag wurde zuletzt bearbeitet: 06.04.2016 14:28 von Lucki.)
(06.04.2016 12:19 )Lucki schrieb: Natürlich geht das, warum probierst Du das nicht gleich selbst aus? Allerdings bringt es nichts, alle Werte einzeln zu lesen. Das menschliche Auge merkt ab Bildwiederholraten von ca. 50/s kein Ruckeln mehr, und viele häufiger updated auch der Monitor nicht. Um das Ruckeln weg zu bekommen, genügt es also, die Update-Rate auf ca. 50 Hz zu erhöhen. Also statt 100 Paketen zu je 50 Werten 500 Pakete zu 10 Werten aus dem Datenpuffer lesen.
50 Hz Update-Rate des Frontpanels ist in LabVIEW sehr viel, vor allem wenn ein Graph noch dauernd autoskaliert werden muss/soll. Typische gute Erfahrungswerte liegen bei 10 - 20 Hz, das langt in der Regel völlig aus.
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!
(06.04.2016 14:34 )jg schrieb: 50 Hz Update-Rate des Frontpanels ist in LabVIEW sehr viel, vor allem wenn ein Graph noch dauernd autoskaliert werden muss/soll.
Natürlich! Das ist der entscheidende Hinweis: Auto-Scale - hier für 8 verschiedene Plots -, dass kann nicht gut gehen! Dieser Hinweis von Jens erspart Dir 5909 Euro!
Lies die Daten von DAQmx und veröffentliche sie in einer Notifikation.
In einer zweiten Schleife kannst du sie aus der Notifikation lesen und anzeigen.
Das geht Ereignis-gesteuert, Publisher-Subscriber-Entwurfsmuster, so schnell wie der Graph anzeigen kann oder im Polling-Modus mit einstellbarere Rate. Im letzteren Fall musst Du den Status der Notifikation lesen.
(07.04.2016 11:39 )abri schrieb: Ich verstehe zwar nicht besonders viel von dem, was Holger mir mitteilen möchte, werde mich aber mal auf Stichwortsuche machen
Ich verstehe das auch nicht. Holger spricht von einer Erzeuger/Verbraucher-Struktur. Für die Datenübertragung von Erzeuger zum Verbraucher werden allerdings eher Queues statt Notifier verwendet.
Ein Erzeuger-Verbraucher-Struktur, mit Datenpufferung zwischen Erzeuger und Verbraucher, ist vom Prinzip her ein sehr gute Sache. Bei Datenerfassung mit NI-Messkarten und DAQmx ist es allerdings so, dass diese Struktur von vornherein schon vorhanden ist: Die Messkarte besorgt autonom die Datenerfassung und stellt die Daten in einen Puffer. Das VI mit der Schleife, in welcher sich DAQmx Read befindet, ist der Verbraucher.
Es mag sicherlich Gründe geben, die bereits gepufferten Daten mittels einer Queue-Struktur nochmals zu pufferrn. Das entspräche dann einer "Erzeuger-Verbraucher.x-Erzeuger.x-Verbraucher-Struktur". Nur: eine Verbesseruung der Performance, oder eine größere Zeitnähe bei der Darstellung der Daten, ist da sicher nicht zu erwarten.
Es ging mir nur darum die Visualisierung auf dem Frontpanel von der eigentlichen Akquisition zu trennen.
Dazu sind Notifikationen gut geeignet, weil es auf Datenverlust hier nicht ankommt. (Die Aktualisierung der Indikatoren findet ja auch asynchrony statt, wenn man nicht explizit synchron einstellt.)
Die Queues sind die richtige Wahl, wenn es darum geht, die Daten an einen Thred zu übertragen, der die Daten verlustfrei speichern soll.
Mein vorherige Beitrag war mitten in der Nacht entstanden, und wollte eigentlich nur auf das Thema neugierig machen.
Also Anja: Queues, Notifikationen etc. sind der Schlüssel zur effizienten modularen LabVIEW Programmierung.
