Laufzeitprobleme - Einzeln ok, mehrfach nicht ok

Hallo Zusammen,

ich nehme mehrere AI kontinuierlich auf. DIe Werte werden aber nur, solange bestimmte Variablen, die anhand des
Prozessablaufes gesetzt werden, gesetzt sind, in ein Array geschrieben.
Die Station besteht aus 3 gleichen, parallelen Plätzen. Diese sind bzw. sollen voneinander unabhägig sein, daher sind auch
parallele Messungen möglich.

Wenn ich nur jeweils an einem Platz messe, funktiniert alles. Starte ich parallel die Messungen, ergeben sich verschiedene Probleme mit der
Messwerterfassung, welche ich auf Ablaufprobleme zurückführe.

Kann das Problem schon bei der Erfassung (siehe Bild) liegen, und diese durch die Schieberegister bzw. den Baustein zur Array-Erstellung
liegen? Es werden etwa 15s Messwerte aufgenommen (d.h. bei 1k Abtastung ca. 15000 Werte. Dies sind doch noch nicht viel für LV, oder?

Die Auswertung diese Werte bzw. Aufnahme und Berechnung weiterer Werte erfolgt parallel in einer anderen While Schleife mit einer for-Schleife bzw. Sequenz.
In einem anderen Thema habe ich hierzu gelesen, dass man in einer Sequenz keine Wartezeit einbauen sollte, da sonst alles andere auch wartet.
Versteh ich das richtig, oder wartet dann nur die eine While-Schleife?

Wie kann ich noch herausfinden bzw. eingrenzen in welchem Programmteil die Ursache liegen könnte?

Vielen Dank für Hilfe.



   

Anzeige

' schrieb:Wenn ich nur jeweils an einem Platz messe, funktiniert alles. Starte ich parallel die Messungen, ergeben sich verschiedene Probleme mit der Messwerterfassung, welche ich auf Ablaufprobleme zurückführe.

Welche Probleme treten denn auf?

Zitat:Kann das Problem schon bei der Erfassung (siehe Bild) liegen, und diese durch die Schieberegister bzw. den Baustein zur Array-Erstellung liegen?

An der Erfassung, also dem DAQmx-Rd, kann es prinzipiell nicht liegen.

Zitat:Es werden etwa 15s Messwerte aufgenommen (d.h. bei 1k Abtastung ca. 15000 Werte. Dies sind doch noch nicht viel für LV, oder?

Das ist nicht viel.
Probleme machen nur Sachen wie ArrayErstellen etc.

Zitat:Die Auswertung diese Werte bzw. Aufnahme und Berechnung weiterer Werte erfolgt parallel in einer anderen While Schleife mit einer for-Schleife bzw. Sequenz.

So ist es im Prinzip richtig.
Im Prinzip kann man so vorgehen: Es gibt eine Task, die Messwerte aufnimmt (also DAQmx-Rd). Diese Task zerlegt die eingelesenen Messwerte und schickt jeder der drei parallelen Prozesse nur genau die Daten, die der Prozess verarbeiten kann (das ist das, was du jetzt mit ArrayIndizieren machst). Ich würde die Daten aber per Queue an die parallelen Prozesse weitergeben. Jeder der parallelen Prozesse kümmerst sich dann selbst darum, ob die Daten in der Queue verwendet werden sollen oder verworfen.

Zitat:In einem anderen Thema habe ich hierzu gelesen, dass man in einer Sequenz keine Wartezeit einbauen sollte, da sonst alles andere auch wartet.

Das ist prinzipiell richtig. Der betreffende Prozess (also die While-Schleife, in der sich die Sequenz befindet) stoppt. Alle anderen, parallelen While-Schleifen werden aber nicht beeinflusst.

Zitat:Versteh ich das richtig, oder wartet dann nur die eine While-Schleife?

Es wartet nur die betreffende Schleife.

Zitat:Wie kann ich noch herausfinden bzw. eingrenzen in welchem Programmteil die Ursache liegen könnte?

Was noch günstig ist, ist folgendes.
Wenn du den DAQmx-Rd ohne Zeitverzug (als z.B. im 2ms Raster) machst, bekommst du eine sehr kleine Menge an Daten, bei 2ms Abtastrate als zwei Daten. Machst du den DAQmx-Rd im 100ms Raster bekommst du 100 Daten, also 50mal mehr. Die Verarbeitungsdauer von 100 Daten ist aber um Potenzen schneller als die Verarbeitung von 50*2 Daten. Also: Die Task, die den DAQmx-Rd macht so gestalten, dass möglichst viele Daten gelesen und zwischenverarbeitet werden können.

Hallo,

Zitat:ZITAT(WolfiB @ 23.08.2010 , 09:22:34) *
Wenn ich nur jeweils an einem Platz messe, funktiniert alles. Starte ich parallel die Messungen, ergeben sich verschiedene Probleme mit der Messwerterfassung, welche ich auf Ablaufprobleme zurückführe.
Welche Probleme treten denn auf?

Die eigentlichen Probleme sind, dass bei Start von 2 oder 3 parallelen Messungen die Auswertung und somit die Werte nicht mehr passen.
Wie und was er gehanu verliert hab ich ncoht nicht herausgefunden. Aber teilweise erhalte ich eben "NaN"´s in den erfassten Werten.
gleichzeitig habe ich das Gefühl, dass das Programm langsamer wird. Da während der Messung Werte in ein Diagramm eintrage, und dieses nicht
merh wie bei Einzelprüfungen gleichmäßig mit Werten gefüllt wird.

Zitat:Kann das Problem schon bei der Erfassung (siehe Bild) liegen, und diese durch die Schieberegister bzw. den Baustein zur Array-Erstellung liegen?
An der Erfassung, also dem DAQmx-Rd, kann es prinzipiell nicht liegen.

ZITAT
Es werden etwa 15s Messwerte aufgenommen (d.h. bei 1k Abtastung ca. 15000 Werte. Dies sind doch noch nicht viel für LV, oder?
Das ist nicht viel.
Probleme machen nur Sachen wie ArrayErstellen etc.

Habe noch nie mit Queues gearbeitet. Sind diese schneller als die Arrays? Oder kann ich die Erzeugung trotz der "wenigen" Werte irgendwie ändern,
um eine Fehlerursache durch die Erstellung der Arrays auszuschließen?

Zitat:Wie kann ich noch herausfinden bzw. eingrenzen in welchem Programmteil die Ursache liegen könnte?
Was noch günstig ist, ist folgendes.
Wenn du den DAQmx-Rd ohne Zeitverzug (als z.B. im 2ms Raster) machst, bekommst du eine sehr kleine Menge an Daten, bei 2ms Abtastrate als zwei Daten. Machst du den DAQmx-Rd im 100ms Raster bekommst du 100 Daten, also 50mal mehr. Die Verarbeitungsdauer von 100 Daten ist aber um Potenzen schneller als die Verarbeitung von 50*2 Daten. Also: Die Task, die den DAQmx-Rd macht so gestalten, dass möglichst viele Daten gelesen und zwischenverarbeitet werden können.

Also die Erfassung der Messwerte wurde ohne Zeitverzögerung gewählt, da die Starts der einzelnen Prüfungen, und damit der Erfassung
bzw. Auswrtung der Messwerte unterschiedlich ist.
Verstehe ich dich da richtig, dass du mir von der kontinuierlichen abräts und eine Erfassung von Bsp.weise immer 100 Werten rätst und diese
dann immer folgend ausgeführt wird? Hatte durch die unterscheidlichen Startpunkte eben zu ungenauigkeiten geführt, da immer ab Start ein ganzes
Datenpaket übertragen wurde, und nicht erst die Werte die ab dem neuen Start relevant waren.

Noch ein Nachtrag:

Die Auswertung (oberes Bild) der Werte wird durch die im Ablauf (unteres Bild) gesetzte Variable gestartet.
Gleichzeitig wird noch während der Messung aus anderen Karten jede 100ms ein Wert berechnet.
Nach der wartezeit in der Sequenz werden dann acuh die aufgenommenen Werte "data" für die Auswertung übertragen.
Vielleicht hilft dies noch zur Eingrenzung des Fehlers.


   

   



Desweiteren wird nur während den einzelnen Messungen von Counterkarten die Signale (Periode und Impulsbreite) für die Berechnung
eines PWM-Signals erfasst (siehe nachfolgendes Bild). Die Auswertung wird im Bild zuvor gemacht. Habe auch schon bei den analogen Karten mit den Problemen,
dass es nur einen Task geben darf gekämpft, ist dies bei den Counterkarten genau gleich und die Probleme können hierdurch zustande
kommen.
   

' schrieb:Aber teilweise erhalte ich eben "NaN"´s in den erfassten Werten.

NaN's in den erfassten Werten?
Anhand deiner Bilder kann ich nicht erklären, wodurch NaN's entstehen. NaN's könnten dann entstehen, wenn man unterschiedlich lange 1D-Arrays zu einem 2D-Array verknüpft - hast du aber nicht.

Zitat:gleichzeitig habe ich das Gefühl, dass das Programm langsamer wird.

Das kann an den Elementen ArrayErstellen liegen - sprich also am allgemeinen Datenmanagement. ArrayErstellen dauert grundsätzlich lange mit Tendenz zu stetig langsamer. Besser als ArrayErstellen ist es, das Array mit der maximalen Länge vorzubesetzen und InArrayErsetzen zu machen.

Zitat:Da während der Messung Werte in ein Diagramm eintrage,

Auch Diagramme sind Zeit- und Platzfresser.

Zitat:Habe noch nie mit Queues gearbeitet. Sind diese schneller als die Arrays?

Schneller nicht. Queues unterstützen lediglich ein optimales Datenmanagement. Sie wirken entkoppelnd zwischen den verschiedenen Prozessen.

Zitat:Oder kann ich die Erzeugung trotz der "wenigen" Werte irgendwie ändern, um eine Fehlerursache durch die Erstellung der Arrays auszuschließen?

Siehe InArrayErsetzen.

Zitat:Also die Erfassung der Messwerte wurde ohne Zeitverzögerung gewählt, da die Starts der einzelnen Prüfungen, und damit der Erfassung bzw. Auswrtung der Messwerte unterschiedlich ist.

Ja, das sehe ich ein. Aber: Ob da ein Vorlauf von 2ms oder einer von 100ms ist, darf für die Auswertung keine Rolle spielen.

Zitat:Verstehe ich dich da richtig, dass du mir von der kontinuierlichen abräts und eine Erfassung von Bsp.weise immer 100 Werten rätst und diese dann immer folgend ausgeführt wird?

Ja, dazu rate ich.

Zitat:Hatte durch die unterscheidlichen Startpunkte eben zu ungenauigkeiten geführt, da immer ab Start ein ganzes Datenpaket übertragen wurde, und nicht erst die Werte die ab dem neuen Start relevant waren.

Ja, das ist richtig. Aber:
Was du hier macht, ist ein "Softwaretrigger für den Beginn von Messdaten". Softwaretrigger sind aber immer ungenau, egal ob das Triggerraster 2ms oder 100ms ist. Dann lieber die Messwerte überprüfen: "Wann übersteigt der Messwert einen bestimmten Wert?".

' schrieb:Vielleicht hilft dies noch zur Eingrenzung des Fehlers.

Eine Ferndiagnose mittels Bilder ist immer schwierig. Besonders in deinem Falle, wenn das Datenmanagement nicht optimal ist.

' schrieb:In einem anderen Thema habe ich hierzu gelesen, dass man in einer Sequenz keine Wartezeit einbauen sollte, da sonst alles andere auch wartet.

Zwar sehe ich bei Dir gar keine Sequenz, aber trotzdem ist hier zur Wartezeit etwas zu sagen:
DAQmx read wartet immer solange, bis die angegebene Anzahl von Samples im Buffer ist. Deshalb sollte man in einer Schleife mit DAQmx Read kein zusätzliches Wait haben. Ewas anderes ist es aber, wenn Du hier an DAQmxRead gar keine Samplezahl angeschlossen hast.
Ich würde das ohne in Not zu sein nie so machen, aber funktionieren tut es so: DAQmxRead wartet nicht (ausgenommen es ist gar keine Sample im Buffer), sondern liest das was gerade im Buffer ist ein. Die Schleife läuft immer mir maximaler Geschwindigkeit, und es sind in der Regel immer eine unterschiedliche Anzahl von Samples.
Du kannst zwar ein Wait in die Schlefe einbauen, die bessere Löung wäre aber, eine vernünftig große Samplezahl für DAQmxRead vorzugeben.
In beiden Fälle wäre der Effekt der, daß die CPU-Auslastung von 100% weg käme - vielleicht dient das der Lösung Deines Problems.

Hallo,

d.h. für mich folgende Aufgaben: (bitte um Korrektur, wenn so nicht richtig)

Step1:
entfernen der direkten Zuweisung der Werte an das Diagramm während der Messung, sondern erst nach Beendigung alle Werte.
Ganz weglassen geht nicht, irgendwas muss visualisiert werden. Aber Zeitmanagementmäßig besser, oder?

Step2_a:
Entfernen von ArrayErstellen, ersetzen durch Array mit Größe Initialsieren und die Werte dann ins ArrayErsetzen. Geht hier nicht besser
in ArrayEinfügen? Sonst muss ich den Index für die Position auch immer mitführen, oder?

Step2_b:
Sollte dies keine Verbesserung bringen, die Queue-Variante benutzen.
Da ich keine Erfahrung mit Queue´s habe: Kann ich diese ebenfalls wie Arrays füllen und an anderer Stelle gesamt ausgeben?

Step3:
Änderung der Messwerterfassung
Hierzu aber folgende Fragen:
- Bisher kontinuerlicher Erfassung. Leider habe ich durch den Softwaretrigger auch ungenauigkeiten in der Messung. Doch woher sind diese genau?
kommen die durch eine ungenaue Widerholrate bei der konrinuirlichen Erfassung, oder meinst du den Zeitverzug vom setzen der Variable bis die ersten
Messwerte in das Array geschrieben werden? Ist der zweite evtl Ursache überhaupt von Relevanz?
- Wenn die Erfassung auf Bsp.weise 100 bzw. 1000 Werte mit der "FiniteSamples" (Endliche Samples) Methode erfasst werden, ist mein "maximaler" Fehler vom Start
der Messung bis zum Übertragen der Werte in das Array dann aber auch nicht kalkulierbar, oder? Die Messwerte werden ständig ausgelesen und zwischengespeichert.
Wenn eine Messung gestartet wird und ein Datenpaket geschrieben wird, kann dieses noch zur Hälfte mit Werten vor dem Start voll sein,oder? Wodurch werde ich
dann genauer?
- Den Start durch eine Wertänderung gestaltet sich schwierig, da bei einem defekten element, sich die Werte nicht ändern, die Messung aber trotzdem gestartet wreden
muss.

' schrieb:entfernen der direkten Zuweisung der Werte an das Diagramm während der Messung, sondern erst nach Beendigung alle Werte.

Sehr sinnvoll.

Zitat:Geht hier nicht besser in ArrayEinfügen? Sonst muss ich den Index für die Position auch immer mitführen, oder?

InArrayEinfügen ist zeit/speicher-mäßig analog zu ArrayErstellen. Das Mitführen eines Indexzählers ist zwar ein kleiner Aufwand, der aber große Auswirkung hat.

Zitat:Da ich keine Erfahrung mit Queue´s habe: Kann ich diese ebenfalls wie Arrays füllen und an anderer Stelle gesamt ausgeben?

Guckst du Onlinehilfe.
In eine Queue kann man reinschreiben und rauslesen, ganz nach belieben. Rauslesen kann man sogar "den ganzen Rest". Natürlich könntest du auch erst komplett reinschreiben und dann komplett auslesen.

Zitat:Leider habe ich durch den Softwaretrigger auch ungenauigkeiten in der Messung. Doch woher sind diese genau?

Auch wenn du eine Schleife so programmiert hast, dass die z.B. 50ms dauern soll, kann es betriebssystembedingt vorkommen, dass diese Schleife mal 250ms lang ist. Wenn dein (allgemeiner) Algorithmus solche Effekte nicht beachtet, siehst du solch eine Zeitverzögerung eben in diversen Daten. Durch eine entsprechende Programmierung (Modularisierung, Queues etc) können solche Seiteneffekt minimiert bis eliminiert werden.

Zitat:kommen die durch eine ungenaue Widerholrate bei der konrinuirlichen Erfassung,

Die ungenaue Wiederholrate wird durch das Management im DAQmx-Treiber automatisch ausgeglichen. Die erfassten Daten sind immer konsistent.

Zitat:oder meinst du den Zeitverzug vom setzen der Variable bis die ersten Messwerte in das Array geschrieben werden? Ist der zweite evtl Ursache überhaupt von Relevanz?

Ein solcher Verzug kann prinzipiell solche Effekte erzeugen. Zwar geht das Programm im Normalfall schnell genug, aber eben nur im Normalfall.

Zitat:Wenn eine Messung gestartet wird und ein Datenpaket geschrieben wird, kann dieses noch zur Hälfte mit Werten vor dem Start voll sein,oder? Wodurch werde ich dann genauer?

Das Vergrößern der Datenpakete dient ja dazu, die Prozessorauslastung zu verringern, nicht dazu die Genauigkeit zu erhöhen.
Ist es denn relevant, dass die Daten an einem genauen Zeitpunkt (Breite des Punktes: 0ms) beginnen? Spielt es denn eine Rolle, wenn der Zeitpunkt eine Ungenauigkeit von 100ms hat?

Hallo,

Zitat:Wenn eine Messung gestartet wird und ein Datenpaket geschrieben wird, kann dieses noch zur Hälfte mit Werten vor dem Start voll sein,oder? Wodurch werde ich dann genauer?
Das Vergrößern der Datenpakete dient ja dazu, die Prozessorauslastung zu verringern, nicht dazu die Genauigkeit zu erhöhen.
Ist es denn relevant, dass die Daten an einem genauen Zeitpunkt (Breite des Punktes: 0ms) beginnen? Spielt es denn eine Rolle, wenn der Zeitpunkt eine Ungenauigkeit von 100ms hat?

Ja, eiegntlich schon. Der Vorgang ist eben so, dass der Start der Messung über einen DI (Hardwarebutton) gestartet wird, dann verschiedene Vorgänge zuvor gemacht werden (kontaktierung etc der Hardware), das geschieht alles in einer "State-Machine", und dann eben die Messung gestartet werden soll, hier wird dann auch erst die Spannung etc angelegt. Wenn nun die Messung erst später beginnt, Ergeben sich schon andere Ergebniswerte als Bspweise 100ms zuvor, da sich der Prüfling intern durch die Spannung ändert (wie bsp ein Heißleiter).
100ms wird der Fehler bisher evtl auch betragen, aber wenn ich dies eben genauer machen kann, möchte ich dies auch tun. Größer sollte der Fehler nicht werden.
Zumal aus den Ergebnisewrten explizit für die Auswertung Bspweise der 7000Wert (bisher also nach 7s) ausgelesen und verglichen wird. Wenn sich das Ergebnisbild verschiebt, stimmt das Ergebnis nicht mehr.

Zitat:Da ich keine Erfahrung mit Queue´s habe: Kann ich diese ebenfalls wie Arrays füllen und an anderer Stelle gesamt ausgeben?
Guckst du Onlinehilfe.
In eine Queue kann man reinschreiben und rauslesen, ganz nach belieben. Rauslesen kann man sogar "den ganzen Rest". Natürlich könntest du auch erst komplett reinschreiben und dann komplett auslesen.

Dann füll ich während der Messung also da Queue langsam mit den Werten und lese diese nach Beendigung komplett in ein Diagramm aus. Kann diese dann auch komplett für die Auswertung in ein Array schreiben, oder? Da ist ja dann kein Zeitkritischer Ablauf mehr vorhanden.

' schrieb:100ms wird der Fehler bisher evtl auch betragen, aber wenn ich dies eben genauer machen kann, möchte ich dies auch tun. Größer sollte der Fehler nicht werden.

Man könnte einen Softwaretrigger schon ziemlich genau machen.
Dazu musst du aber die Erfassungsschleife in ein eigenständiges SubVI auslagern (was an sich schon etwas kompliziert wird). Da dieses SubVI kein FP hat (braucht), geht so für das Erfassen alles viel schneller. Dieses SubVI kannst du in 20ms, möglicherweise sogar 1ms, laufen lassen. Voraussetzung ist natürlich das Verwenden einer, respektive mehrerer Queues.
Das Verwenden eines SubVIs für die Erfassung wirft dein komplettes Programmierkonzept um - und ist so gesehen für dich jetzt aufwändig.

Zitat:Zumal aus den Ergebnisewrten explizit für die Auswertung Bspweise der 7000Wert (bisher also nach 7s) ausgelesen und verglichen wird. Wenn sich das Ergebnisbild verschiebt, stimmt das Ergebnis nicht mehr.

Das sehe ich natürlich ein.

Zitat:Dann füll ich während der Messung also da Queue langsam mit den Werten und lese diese nach Beendigung komplett in ein Diagramm aus. Kann diese dann auch komplett für die Auswertung in ein Array schreiben, oder?

Klar.
Nebenbei bemerkt: Ein kleiner Aufwand besteht schon, Queuedaten in Arraydaten zu konvertieren. Aber dafür bist du ja Programmierer geworden.