Auswertung von Schwellwerten / Aufzeichnung in TDMS

Hallo liebe LabVIEW-Freunde,

zur Versuchsauswertung werden insgesamt 9 Spannungssignale über ein NI9220 als TDMS aufgezeichnet - die gesamte Messung umfasst mehrere Zyklen die wiederum in einzelne Sequenzen aufgeteilt sind.
Um den aktuellen Zustand der Anlage festzustellen werden in den ersten beiden Kanälen 5 Volt Schaltsignale ausgewertet ("Operate" startet und beendet den jeweiligen Zyklus, "Sequenz" gibt den derzeitigen Status im aktuellen Zyklus aus).
Da die einzelnen Zyklen eine unterschiedliche Dauer haben, soll im TDMS die aufgelaufene Zykluszeit (Summieren "dt") und die zugehörige Sequenz-Nummer mitgeschrieben werden, zudem wird dadurch die anschließende Auswertung in Excel für meine Kollegen ermöglicht.

Das VI habe ich in Producer-Consumer-Struktur über mehrere Queues und Melder aufgebaut:
- Producer Loop (Analog, NChan, NSamp), kontinuierlich Messung, 1000 Samples/s → im Anhang vereinfacht als Schieberegler
- Analysis Loop (wertet die Schwellwerte aus und bereitet die Daten zum schreiben in TDMS auf)
- Logging Loop (schreibt die Daten in TDMS) → im Anhang vereinfacht als Anzeige
- Display Loop (Bildschirmanzeige von Graphen)

Leider wird in meinem VI nur alle N-Samples auf den nächsten Zyklus / Sequenz weitergezählt (Maximalwert Array größer 5 Volt), das komplette durchsuchen des Arrays nach Werten > 5V mittels Schleife war leider zu langsam. Gibt es hier eine schnellere Auswertung des Schwellwerts (z.B. über "einfache Triggererkennung") und wie kann ich dies ohne Zeitverzögerung an TDMS-Write weitergeben?

Cycles, Cycletime und Sequence rechne ich derzeit mit einer "For-Schleife" auf die Anzahl Samples hoch, damit ich sie in der TDMS mitschreiben kann - gibt es hier eine bessere Möglichkeit?

Sind so viele einzelne Queues und Melder überhaupt ratsam?

Wäre es vielleicht leichter, die aktuellen Zustände der Anlage über ein NI9375 ohne größere Zeitverzögerung zu erfassen und auszuwerten (Analog- und Digital-Modul befinden sich jedoch leider in getrennten Netzwerk-Chassis)?

Ich hoffe, ihr entschuldigt meine wahrscheinlich sehr laienhafte Programmierweise und könnt mir trotzdem gute Tipps geben.


Danke und schöne Grüße,
Gerhard

Hallo Nase,

Zitat:Producer Loop (Analog, NChan, NSamp), kontinuierlich Messung, 1000 Samples/s

Dein Producer erzeugt momentan 10kS/s…

Leider wird in meinem VI nur alle N-Samples auf den nächsten Zyklus / Sequenz weitergezählt (Maximalwert Array größer 5 Volt),
Wie soll es denn anders funktionieren?
Du sendest einen Block von Samples an die Auswertung und prüfst, ob dein Trigger (mindestens einmal) erreicht wurde. Du prüfst nicht, wie oft der Trigger erreicht wurde…

Zitat:das komplette durchsuchen des Arrays nach Werten > 5V mittels Schleife war leider zu langsam.

Wie bitte?
Das Durchsuchen von 1000 Samples in einer Schleife ist zu langsam? Was hast du denn für einen Rechner?

Cycles, Cycletime und Sequence rechne ich derzeit mit einer "For-Schleife" auf die Anzahl Samples hoch, damit ich sie in der TDMS mitschreiben kann - gibt es hier eine bessere Möglichkeit?
Da dt anscheinend fest definiert ist, kann man auch eine Rampe mit dt multiplizieren, statt Sample für Sample eine einzelne Addition für CycleTime durchzuführen…
(Du kennst dt und die Anzahl der Samples pro Block!)

Zitat:Sind so viele einzelne Queues und Melder überhaupt ratsam?

Ja.
(Ich verwende geschätzt 100-200 Queues in meiner Prüfstandssoftware…)

Hallo Gerd,

vielen lieben Dank für deine schnelle Antwort!
Stimmt, die Wartezeit ist beim Producer momentan Faktor 10 zu kurz, habe ich nur für's Forum so gesetzt, damit's mit dem Schieberegler flüssiger läuft...

Tja, das mit dem Rechner ist in der Firma leider wirklich etwas schwierig - aktuell ist es noch ein Core-Duo, aber demnächst bekomme ich zumindest einen i5 mit SSD (allerdings leider wieder nur ein klassischer "Office-PC"), seufz.
Mir ist bewusst, dass mit der bisherigen Funktion (Maximalwert Array) nur jeder komplette Block von Samples einmal ausgewertet und im Gesamten geschrieben wird, aber damit eine positionsgenaue Schwellwertfindung überhaupt Sinn macht, muss ich ja im Anschluss auch alle restlichen Kanäle des Blocks jeweils an der richtigen Stelle teilen, um die relevanten Werte zu loggen.
Habe im Anhang ein Beispiel-VI zum Teilen des Blocks mit zwei Varianten zusammengestellt - welche ist im Prinzip die ressourcensparendste (Thema Rechnerleistung)? Oder gibt es insgesamt eine bessere Lösung dafür?

Das mit der Rampe ist eine gute Idee, werde ich mal versuchen, dankeschön!
Zumindest bin ich schon mal mit den Queues nicht direkt auf dem Holzweg...


Schöne Grüße,
Gerhard

Hallo Gerhard,

Zitat:Habe im Anhang ein Beispiel-VI zum Teilen des Blocks mit zwei Varianten zusammengestellt - welche ist im Prinzip die ressourcensparendste (Thema Rechnerleistung)?

Das ist eine schlecht formulierte Frage: welche Resource willst du sparen, CPU-Leistung oder RAM?

Ich würde Variante 2 bevorzugen:
- besser lesbar
- die Schleife kann man parallelisieren
- die Konstante "9" gehört da nicht hin, dafür gibt es Autoindizierung!
   

Zitat: Oder gibt es insgesamt eine bessere Lösung dafür?

Das hängt von deinen genauen Requirements ab…