Probleme mit Signalverlaufsgraphen

Hallo LabView Gemeinde! Ich bin noch ziemlicher Anfänger im Bereich LabView und stoße gerade auf ein paar Probleme, die ich nicht mehr gelöst bekomme. Ich hoffe ihr könnt mir ein paar Anregungen dazu geben.

Am besten ich gebe kurz wieder wie unsere Messkette genau aufgebaut ist. Das Ziel ist es, mit einem PXI System (2,93 GB Arbeitsspeicher, 4 Kerne a 2,9 GHz) und den Messkarten 6259 und 6132, an einem Versuchsstand AE, Kräfte usw. zu erfassen. Dabei soll die 6259 Messkarte mit 50kHz und die 6132 mit 1MHz abtasten. Des Weiteren läuft die 6132 nur Differentiell und die 6259 soll hauptsächlich im RSE betrieben werden, wird aber später auch von einer anderen Gruppe Differentiell genutzt.

Mittels Queues konnte ich mein Skript lauffähig machen, muss diese aber leider auf ein Größe von 500 begrenzen. Soweit ich dass bei den Queues verstanden habe muss ich dann ein Real Time System einsetzen um keine Verluste zu bekommen. Es wird gespeichert und ich kann mir die Graphen auch anschauen. Soweit geht es.

Jetzt zu meinem Hauptproblem: Die Graphen flackern zum einen, leider hilft da auch nicht der Modus Glätten, außerdem springen die ganze Zeit die Achsen (zumindest wenn Autoskalierung aktiviert ist, worin wohl auch der Fehler liegt). Feste Grenzen wären zum einen natürlich die Lösung. Nur wenn ich die X Achse auf 1 Sekunde begrenze, wird diese nur leider nicht ausgefüllt. Dabei werden beide Messkarten 1:1 ausgelesen. Zuerst dachte ich es liegt an meiner Verzögerungsquelle in der While Schleife (nur damit es nicht ganz so schlimm flackert) oder an den Queues, deshalb habe ich die Graphen dann in die Signalerzeugungsschleifen gepackt und gehofft damit das Problem zu lösen und das PXI nicht zu überlasten. Es hilft aber leider auch nicht. Selbst wenn die Graphen direkt mit DMQ Lesen verbunden werden, wird nur ein Signal der Länge von 2E-5 dargestellt. Zumindest die überwiegende Zeit, denn ab und an springt der Bereich und es kommt mehr an, aber immer noch deutlich weniger als eine Sekunde. Vielleicht kann da ein Ringpuffer helfen? Darüber muss ich mir aber erstmal etwas mehr anlesen.

Wie ihr seht bin recht ratlos. Ich habe jetzt schon einiges versucht und auch viel hier im Forum gelesen, habe bisher aber noch nicht die Lösung gefunden. Wahrscheinlich ist es recht einfach und ich sehe nur den Wald vor lauter Bäumen nicht. Einen Schnitzer meinerseits halte ich auch noch für sehr wahrscheinlich. Deshalb bereits jetzt vielen Dank für eure Anregungen oder Lösungen!

Beste Grüße Afti3l

Hallo Afti,

Zitat:Mittels Queues konnte ich mein Skript lauffähig machen

"Skript"? Du meinst wohl VI oder dessen BD…

Zitat:muss diese aber leider auf ein Größe von 500 begrenzen.

Warum?

Zitat:Soweit ich dass bei den Queues verstanden habe muss ich dann ein Real Time System einsetzen um keine Verluste zu bekommen.

Nein. Wieso?

Zitat:Es wird gespeichert und ich kann mir die Graphen auch anschauen.

Ja.

Zitat:Soweit geht es.

Jein.

Ganz großer Fehler: eine Queue mit einem Producer (Messschleife) und zwei Verbrauchern (Anzeige & Speicherung)!
Dafür ist eine Queue nicht gemacht! Eine Queue darf durchaus mehrere Erzeuger, sollte aber nur einen Verbraucher haben!

Lese die Queue nur in der Speicherschleife und reiche den aktuellen Status für die Anzeige per Notifier weiter!

Warum musst du überall den Queue-Status abfragen, obwohl du dessen Ausgaben nie verwendest?

Noch weitere Fehler/Missstände:

Zitat:Nur wenn ich die X Achse auf 1 Sekunde begrenze, wird diese nur leider nicht ausgefüllt. … Selbst wenn die Graphen direkt mit DMQ Lesen verbunden werden, wird nur ein Signal der Länge von 2E-5 dargestellt.

Deine DAQmxRead fragen nur die gerade verfügbaren Samples ab. Warum fragst du nicht Blöcke mit definierter Sampleanzahl ab? Dann könnte sich auch das Problem der zappelnden Graphen relativieren…

- Deine zwei Queues werden in einer Schleife abgefragt, d.h. die langsamere Queue kann die schnellere ausbremsen. Das ist kein wirklich durchdachtes Design…
- Die Anzeigeschleife wird zusätzlich noch durch eine Wartezeit ausgebremst - dies ist für die Anzeige sinnvoll, aber nicht für die Queue…
- Warum schreibst du einen Wert in ein Terminal und zusätzlich noch in eine lokale Variable eben dieses Terminals? Warum nutzt du keine Drähte, um Daten weiterzureichen? (Das bezieht sich auf deine Pfadangaben…)

Hallo GerdW,

vielen Dank für deine ausführlichen Tipps und Verbesserungen. Damit hast du mir schon mal sehr geholfen. Auch verstehe ich jetzt einige Zusammenhänge besser!

Zitat:"Skript"? Du meinst wohl VI oder dessen BD…

Oh ja, natürlich meinte ich VI. Bei uns am Institut hat sich auch Messskript eingebürgert. Deshalb der falsche Terminus!

Zitat:Warum?

Es lief mit einer maximalen Queuegröße von 500 am stabilsten. Wenn -1 oder etwas größeres als 500 gewählt wurde, wurden nur 1,6 Sekunden in die TDMS geschrieben bzw. das PXI hatte nach sehr kurzer Zeit eine 100% Kernauslast und hat sich neugestartet. Aber ich hoffe dass sich deine Verbesserungsvorschläge auch darauf auswirken.

Zitat:Soweit ich dass bei den Queues verstanden habe...

Zitat:Nein. Wieso?

Mein Fehler, ich hatte etwas zur Speicherreservierung mit Queues durcheinandergebracht.

Zitat:Ganz großer Fehler: eine Queue mit einem Producer (Messschleife)...

Ah, ok. Das erklärt so einiges. War mir bisher nicht bewusst.

Zitat:Lese die Queue nur in der Speicherschleife und reiche den aktuellen Status für die Anzeige per Notifier weiter!

Werde ich machen. Ich hatte bisher nur Queues oder Melder verwendet. Aber nicht kombiniert.

Zitat:Warum musst du überall den Queue-Status abfragen, obwohl du dessen Ausgaben nie verwendest?

Zum besseren Verständnis und einfacheren Einarbeitung wurden mir VI's von Vorgängern gegeben. Dort wurden die Queues so aufgezogen. Aber eigentlich hätte ich auch durch den Namen des Baussteins darauf kommen können dass es nicht notwendig ist.

Zitat:Deine DAQmxRead fragen nur die gerade verfügbaren Samples ab. Warum fragst du nicht Blöcke mit definierter Sampleanzahl ab? Dann könnte sich auch das Problem der zappelnden Graphen relativieren…

Klingt gut, werde ich machen. Die meisten VI's hier am Institut arbeiten ohne Blöcke mit definierter Sampleanzahl. Bin dadurch auch gar nicht auf die Idee gekommen dass es daran liegen könnte.

Zitat:- Deine zwei Queues werden in einer Schleife abgefragt, d.h. die langsamere Queue kann die schnellere ausbremsen. Das ist kein wirklich durchdachtes Design…

Klingt logisch! Muss ich ändern.

Zitat:- Die Anzeigeschleife wird zusätzlich noch durch eine Wartezeit ausgebremst - dies ist für die Anzeige sinnvoll, aber nicht für die Queue…

Verstehe.

Zitat:- Warum schreibst du einen Wert in ein Terminal und zusätzlich noch in eine lokale Variable eben dieses Terminals? Warum nutzt du keine Drähte, um Daten weiterzureichen? (Das bezieht sich auf deine Pfadangaben…)

Mich hatten die Drähte gestört. Ich fand es mit Drähten an dieser Stelle zu unübersichtlich, außerdem hatten mich auch die Lokalen Variablen begeistert. Im Prinzip ist es wohl Spielerei. Werde ich auch ändern.

Also nochmals vielen Dank! Ich kann jetzt gleich wieder ans PXI und werde deine Vorschläge direkt testen.
Gruß Afti3l

Hallo Afti,

Zitat:Im Prinzip ist es wohl Spielerei.

"Im Prinzip" ist es eine Programmierweise, die einerseits Rube-Goldberg ist und andererseits komplett am DATAFLOW-Prinzip vorbeigeht…