Parallele Datenaufnahme, Erz-Verbr verbraucht irgendwann nicht mehr

Hallo LV-Foristen,

ich habe ein Problem.
Mein Chef fand es passend , mich an ein Laborgruppen-Projekt zu setzen, welches seit 6 Jahren nicht in Gang zu kriegen ist, es geht um eine "Filmwaage". Kosten hat sie schon genug verschlungen (daher auch nur LV 7.1), 4 Diplomanden haben sich, mit mehr oder weniger logischem Verständnis, daran versucht, nun soll ich sie zum Laufen kriegen.
Das Ding ist komplett selbst gebaut, was dann "leider" auch die komplette Programmierung in LV beinhaltet.
Ärgerlicherweise beschränkten sich meine LV-Erfahrungen auf die Programmierung einer Steuer- und Auswertesoftware eines Spektrographen vor 2 Jahren, nur über einen Tag. Daher kenn ich mich einfach nicht mit LV aus. Und ich bin hier im Haus noch derjenige, der sich damit am "meisten" auskennt.
Aber genug von meiner Inkompetenz, kommen wir zu meinem Problem:

Ich tüftel zur Zeit an der Motorsteuerung, simples nach links oder rechts fahren, dabei in kleinen Intervallen @1s Aufnahme von insg. 4-5 Messparametern. Dabei soll die Motorsteuerung möglichst NICHT von der Aufnahme der Daten beeinflusst werden.
Ich könnte natürlich ganz simpel "1cm fahren, Daten aufnehmen, 1cm fahren, Daten aufnehmen ..." programmieren, so war es auch ganz am Anfang (funktionierte dennoch nicht ).
Das Problem dabei ist die Bewegung der Barriere (durch den Motor getrieben), welche sich teilweise in Flüssigkeit befindet. Eine solche "step-by-step" Lösung führt zu starken Stoßwellen, welche wiederum die Probe massiv beeinflussen.

Also habe ich mich, nach langer und hoffentlich ausgiebiger Lektüre verschiedener Quellen, auch dieses Forums, an die "Erzeuger-Verbraucher-Schleife" rangemacht. Auf einmal kann ich mit minimaler Verzögerung in 50-Schritt-Blöcken (damit alle 50 Schritte die Stopbedingungen geprüft werden) fahren und alle 4 Blöcke die Motorposition aus der Erzeuger-Schleife in die Verbraucher-Schleife geben. Dabei läuft die Erzeuger-Schleife weiter, auch wenn der Verbraucher noch am arbeiten ist. Nahezu paralleler Ablauf, juhu!
Dabei gibt es aber zwei Probleme:
1. Wenn ich die Verbraucher-Schleife zu voll packe (mit noch mehr Graphen, noch mehr Datenaufnahmen) oder den Waittimer in der Verbraucherschleife (zur Beeinflussung des Ausgabe-Intervalls) zu hoch setze (zB testweise 5000ms), läuft zwar der Erzeuger normal weiter, jedoch "streikt" die Verbraucherschleife irgendwann (meist gleich ab dem ersten Durchlauf).
D.h. es werden ständig neue Parameter in die Queue gesetzt, die Verbraucher-Schleife holt sich jedoch keine raus, obwohl sie zZ GARnichts tut. Und es ist nicht so, dass sie mal einen Durchlauf "auslässt", sie hört dann komplett auf zu arbeiten. Warum und wie kann man das beheben?

2. Man hört ganz deutlich, dass die Motorsteuerung kurz aussetzt, wenn die Verbraucher-Schleife arbeitet. Das ist aus oben genannten Gründen unschön. Dass es nicht an der Übergabe des Parameters in die Queue in der Erzeuger-Schleife liegt, kann ich schnell sehen, wenn ich die gesamte Datenauswertung (4 Graphen abbilden, Messwerte in 2 Dateien schreiben) aus dem Verbraucher rauslösche - dann funktioniert das nämlich "reibungslos". Ich kenne das Problem von (alten?) LabView(-Versionen?), dass das Programm überhaupt nicht damit umgehen kann, wenn nebenbei noch was anderes passiert (Mausclick ahoi) und dann sofort hakt. Ist das hier auch der Grund? Hakt die Motorsteuerung, weil die Verbraucherschleife nun auch Rechenleistung benötigt? Wenn ja, kann man das beheben? Wenn nein, wie kann man das beheben?


Ich habe mal sowohl Screenshots als auch ein Beispiel-VI (Queue_Template2.vi) samt SubVIs angehängt (die letzten 2 SubVIs folgen im nächsten Post).

Ich bitte daher um Hilfe (auch abseits der genannten Probleme, bin immer dafür zu haben)

Danke und mit freundlichen Grüßen,
Niels

---

Anhänge Teil 2

Anzeige

Hallo Niels

Ich hab mir mal deine VI's angesehen und ein paar mögliche Fehler entdeckt:

1. Deine Überprüfung des Tsensors wird genau 1x ausgeführt, ist dies so gewollt?
2. Weshalb bremst du deine Consumer-Loop künstlich aus? Grundsätzlich wird diese nur ausgeführt, sobald Daten anliegen.
3. Deine Abspeicherungs-Funktionen bremsen deine Applikation extrem aus, da jedes mal eine Verbindung zum File hergestellt werden muss. Besser wäre es die Daten (Suchstichwort: Shift-Register) zu sammeln und nach Ende der Schleife abzuspeichern.
4. Ein Queue kann jeden beliebigen Datentyp versenden unter anderem auch Double, anstatt String einfach einen Double anhängen, damit sparst du dir auch die unnötigen Umwandlungen.
5. Mit deinem momentanen Aufbau ist es nicht möglich die Richtung zu ändern, ist dies gewollt? Ansonsten müsste die "True/False" Abfrage innerhalb der While-Schleife sein.
6. Verwende nicht lokale Variablen, wenn du den Wert direkt anhängen könntest (Tsensor;Stop;Graph: lateral pressure over area)

Grundsätzlich werden höchstwahrscheindlich die Wartezeit der Verbraucher-Loop und die unnötigen Speichervorgänge einen Strich durch die Rechnung gemacht haben

Hoffe das hilft dir weiter!

Gruss Marc

(10.07.2012 12:14 )M Nussbaumer schrieb:  Hallo Niels
Ich hab mir mal deine VI's angesehen und ein paar mögliche Fehler entdeckt:

1. Deine Überprüfung des Tsensors wird genau 1x ausgeführt, ist dies so gewollt?
2. Weshalb bremst du deine Consumer-Loop künstlich aus? Grundsätzlich wird diese nur ausgeführt, sobald Daten anliegen.
3. Deine Abspeicherungs-Funktionen bremsen deine Applikation extrem aus, da jedes mal eine Verbindung zum File hergestellt werden muss. Besser wäre es die Daten (Suchstichwort: Shift-Register) zu sammeln und nach Ende der Schleife abzuspeichern.
4. Ein Queue kann jeden beliebigen Datentyp versenden unter anderem auch Double, anstatt String einfach einen Double anhängen, damit sparst du dir auch die unnötigen Umwandlungen.
5. Mit deinem momentanen Aufbau ist es nicht möglich die Richtung zu ändern, ist dies gewollt? Ansonsten müsste die "True/False" Abfrage innerhalb der While-Schleife sein.
6. Verwende nicht lokale Variablen, wenn du den Wert direkt anhängen könntest (Tsensor;Stop;Graph: lateral pressure over area)

Grundsätzlich werden höchstwahrscheindlich die Wartezeit der Verbraucher-Loop und die unnötigen Speichervorgänge einen Strich durch die Rechnung gemacht haben
Hoffe das hilft dir weiter!
Gruss Marc

Hi Marc,

Das hilft mir schonmal sehr viel weiter, Danke.

zu:
1. Ja, es geht da ja nur darum, ob er unrealistisch hohe oder tiefe Temperaturen misst (Arbeitsbereich liegt zw. Zimmertemp und 40°C). Die Messung selbst dauert ja nur ~10min.
2. Ich habe gehofft, dass ich durch künstliches Ausbremsen das Stocken meiner Motorsteuerung verringere. Aber er soll natürlich gerne jeden Messwert mitnehmen, daher hast du Recht, macht keinen Sinn.
3. Das klingt sehr gut, würde viel im HauptVI (welches noch um einiges größer ist ) entschlacken. Guck ich mir mal an
4. Das sieht mein LV anders (s. Screenshot). Oder habe ich Dich mißverstanden?
5. Jo, das ist iO. Dazu ist das VI eh nur der Ausschnitt für "move barrier back", also in eine Richtung.
6. Ok, mach ich.

Hallo kiX,

zu 4.: du kannst natürlich nur den Datentyp mit deinem Queue "transportieren", den du bei der Erstellung deines Queues definiert hast.


Gruß,
Soean

Hallo Soean,

ja, das hab ich eben auch gemerkt
Einfach ein DBL an "Obtain Queue" gehängt, dann gings.
Jetzt muss ich mich nur noch mit Shift-Registern beschäftigen.

Gruß,
Niels

hier mal ein kleines Update:

Viel hat sich nicht verändert, und manche Probleme bestehen immer noch.

Die Waittime ausm Consumer wurde rausgeworfen, DBL wird direkt in die Queue eingespeist, unnötige Lokale Variablen wurden entfernt (s. Anhang).

Bislang ist es nicht passiert, dass der Consumer einfach nicht mehr gearbeitet hat, selbst wenn ein neues Element in die Queue gesetzt wurde. Schonmal gut.


Was immernoch passiert, ist, dass die Motorsteuerung stockt, wenn irgendwas gemacht wird. Es dauert anscheinend recht lange, die aktuelle Motorposition an die Queue weiterzugeben (währenddessen kann der Motor nicht weiter), aber noch mehr stockt er, wenn der Consumer läuft.

Liegt es am (für heutige Verhältnisse) lahmen PC (2,4GHz Celeron, 2GB Ram) oder kann man das irgendwie beheben?
Eine wirklich parallele Abarbeitung (mit höchster Prio beim Producer) wäre wirklich wünschenswert. Gibts da eine Alternative zum Producer-Consumer-Design?


Kurz noch zum Consumer (s. Screenshot):
Nach meinem Empfinden sollte er die gesamten (alten) Messdaten aus Values1.txt lesen, pro Schleifendurchgang je einen Teilstring anhängen und bei Beenden der Schleife den gesamten String wieder in Values1.txt abspeichern. Tut er aber nicht. Starte ich das Programm mit aktivierten Stopschaltern, speichert er (für den einen Durchlauf) die Messdaten ab, lasse ich jedoch das Programm einfach laufen und beende dann nach ein paar Durchgängen über (beide) Stop-Schalter, speichert er NICHTS ab.

Was geht, ist in jedem Durchgang einen String in Values2.txt abzuspeichern. Er wird dadurch nicht spürbar langsamer (er IST es ja schon ), aber wirklich elegant finde ich das nicht.

Jemand ne Idee?

Anzeige

(12.07.2012 14:57 )kiX schrieb:  hier mal ein kleines Update:

Viel hat sich nicht verändert, und manche Probleme bestehen immer noch.

Die Waittime ausm Consumer wurde rausgeworfen, DBL wird direkt in die Queue eingespeist, unnötige Lokale Variablen wurden entfernt (s. Anhang).

Bislang ist es nicht passiert, dass der Consumer einfach nicht mehr gearbeitet hat, selbst wenn ein neues Element in die Queue gesetzt wurde. Schonmal gut.


Was immernoch passiert, ist, dass die Motorsteuerung stockt, wenn irgendwas gemacht wird. Es dauert anscheinend recht lange, die aktuelle Motorposition an die Queue weiterzugeben (währenddessen kann der Motor nicht weiter), aber noch mehr stockt er, wenn der Consumer läuft.

Liegt es am (für heutige Verhältnisse) lahmen PC (2,4GHz Celeron, 2GB Ram) oder kann man das irgendwie beheben?
Eine wirklich parallele Abarbeitung (mit höchster Prio beim Producer) wäre wirklich wünschenswert. Gibts da eine Alternative zum Producer-Consumer-Design?


Kurz noch zum Consumer (s. Screenshot):
Nach meinem Empfinden sollte er die gesamten (alten) Messdaten aus Values1.txt lesen, pro Schleifendurchgang je einen Teilstring anhängen und bei Beenden der Schleife den gesamten String wieder in Values1.txt abspeichern. Tut er aber nicht. Starte ich das Programm mit aktivierten Stopschaltern, speichert er (für den einen Durchlauf) die Messdaten ab, lasse ich jedoch das Programm einfach laufen und beende dann nach ein paar Durchgängen über (beide) Stop-Schalter, speichert er NICHTS ab.

Was geht, ist in jedem Durchgang einen String in Values2.txt abzuspeichern. Er wird dadurch nicht spürbar langsamer (er IST es ja schon ), aber wirklich elegant finde ich das nicht.

Jemand ne Idee?

Nimm mal das Wait aus der Consumer-Loop ganz raus, wenn du das auf 0 setzt bekommt die Schleife Priorität (siehe Kontexthilfe zur Wait-Funktion). Ausserdem anstatt ein 2.Stop in der Consumer-Loop zu verwenden würde ich einfach den Fehlerausgang an die Stopbedingung anschliessen (oder unboundle und den Boolean-Wert des Fehlerclusters verwenden falls das in 7.1 noch nicht geht).

Das Problem mit den nicht gespeicherten Werten mit dem Shift-Register konnte ich nicht nachvollziehen Nimm mal den 2.Stop Knopf wie oben beschrieben raus und schau mal ob es dann funktioniert.

Gruss Marc

Hmm...deinen Task hast du mit dem MAX erstellt, ja? Mach das mal über die dafür vorgesehenen VIs, dann ist deutlicher, was du konfiguriert hast. Für den Anfang ist das am einfachsten, wenn du den DAQ assistand verwendest und du diesen danach per rechte Maustaste "in DAQmx Code Umwandeln" in VIs umwandelst. Falls das bei 7.1 noch nicht geht, an den Examples orientieren und den Task über VIs erstellen. Danach können wir hoffentlich mehr sehen.

(13.07.2012 09:08 )M Nussbaumer schrieb:  Nimm mal das Wait aus der Consumer-Loop ganz raus, wenn du das auf 0 setzt bekommt die Schleife Priorität (siehe Kontexthilfe zur Wait-Funktion). Ausserdem anstatt ein 2.Stop in der Consumer-Loop zu verwenden würde ich einfach den Fehlerausgang an die Stopbedingung anschliessen (oder unboundle und den Boolean-Wert des Fehlerclusters verwenden falls das in 7.1 noch nicht geht).

Das Problem mit den nicht gespeicherten Werten mit dem Shift-Register konnte ich nicht nachvollziehen Nimm mal den 2.Stop Knopf wie oben beschrieben raus und schau mal ob es dann funktioniert.

Gruss Marc

Hallo Marc,

hm, an den Wait=0 hab ich garnicht gedacht, das mach ich mal.
Den Fehlerausgang hatte ich vorher als Stopbedingung drin, mit dem selben Ergebnis. Der Consumer-Stop war nur dafür drin, um zu prüfen, ob der Consumer auch nochmal läuft, wenn ich den Producer beende (was er gemäß Producer-Bedingung eigentlich sollte). Tut er aber so oder so nicht.

(13.07.2012 09:57 )Soean schrieb:  Hmm...deinen Task hast du mit dem MAX erstellt, ja? Mach das mal über die dafür vorgesehenen VIs, dann ist deutlicher, was du konfiguriert hast. Für den Anfang ist das am einfachsten, wenn du den DAQ assistand verwendest und du diesen danach per rechte Maustaste "in DAQmx Code Umwandeln" in VIs umwandelst. Falls das bei 7.1 noch nicht geht, an den Examples orientieren und den Task über VIs erstellen. Danach können wir hoffentlich mehr sehen.

Hallo Soean,

Meinst du den DO_P0-Task? den hab ich selbst nicht erstellt, das war einer der Vorgänger. Hat für die Motorsteuerung sehr gut funktioniert, daher hab ich das so belassen. Kann ich mir aber mal anschauen am Montag.

erneut ein Update:

Ich habe den Speichervorgang hingekriegt, nun wird nurnoch beim Verlassen der Consumerloop gespeichert.
Auch der Waittimer ist gänzlich rausgeflogen.
Den Fehlerausgang von "Dequeue Element" habe ich mit der Stopbedingung verbunden, nun endet die C-Loop auch, nachdem die P-Loop stopt.
Ich habe in der P-Loop die Weitergabe von Elementen in die Queue geändert, sodass die Elemente ans ENDE der Queue gegeben werden (und in der C-Loop vorne abgenommen werden). Ich hoffte, dadurch die C-Loop dazu zu bringen, die Queue vollständig abzuarbeiten, auch wenn die P-Loop stoppt.

Zwei Probleme bleiben jedoch bestehen:

1. Im Realtime-Mode ignoriert die C-Loop das letzte Element, welches durch die zweite Queue-Bedingung (Element einfügen bei Stop) eingefügt wird. Im Highlight-Mode klappt das. Ich vermute, dass im RT-Mode die Stopinfo zur C-Loop gelangt, bevor diese das letzte Element "anfasst", und somit die Queue "überschreibt". Kann man das beheben?

2. Weiterhin, obwohl ich die unnötigen Speicherzugriffe aus der C-Loop entfernt habe und die Prio durch Waittimer=0 entfernt wurde, stockt die Motorsteuerung deutlich, wenn die C-Loop arbeitet (wie gesagt, wenn die C-Loop leer ist, gehts).
Ich würde ja gerne testen, ob die Sache "rund" läuft, wenn ich alles zu ner .exe kompiliere. Problem ist, dass ich keinen Application Builder habe. Und ob ich einen kaufe, ohne dass ich weiß, obs danach läuft... weiß ich nicht.
Hierran schließen sich zwei Fragen an:
- Habt ihr ähnliche Erfahrungen bei Producer-Consumer-Schleifen gemacht und die Probleme gelöst?
- Gibt es eventuell eine sinnvolle Alternative zum Producer-Consumer-Konzept für den gewünschten parallelen Ablauf?


Ich danke euch erneut für die Hilfe.
das neue VI ist angehängt, die SubVIs sind unverändert, s. ersten Post


edit: Was die Taskerstellung angeht, habe ich da noch nicht wirklich durchblicken können. Ich fände es merkwürdig, wenn es daran läge, wo doch die Motorsteuerung selbst (alleine wie auch bei fast leerer Consumer-Loop) gut läuft. Wenn es aber wirklich daran liegen kann, steig ich da nochmal tiefer ein.