INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.


Antwort schreiben 

Pausieren von parallel ablaufenden Producer/Consumer Schleifen



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!

21.06.2010, 15:14
Beitrag #11

Aleph1 Offline
LVF-Gelegenheitsschreiber
**


Beiträge: 51
Registriert seit: Sep 2005

7.1 + 8.6.1
2005
de_en

69120
Deutschland
Pausieren von parallel ablaufenden Producer/Consumer Schleifen
Hallo
@dimitri84 und IchSelbst: Danke für die Hinweise. Das kann ich sicherlich irgendwann mal brauchen, Sieht gut aus.
Allerdings ist bei mir eher das speichern und archivieren der DatenMENGE mit handelsüblichen Methoden ein Problem, das mich aber grad net kratzen soll. Die Messungen können mehrere Tage laufen, da läuft mir alles über. von der Zeit die ich anschließend fürs Post processing benötige, will ich mal gar net reden. Daher brauch ich auch die von mir geschriebene "Kompression" der Messdaten, die, kurz gesagt, nix anderes als ne Signalmittelung ist.
Trotzdem vielen herzlichen Dank für Eure geilen Vorschläge

Gruß
Karl
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
21.06.2010, 17:46
Beitrag #12

Lucki Offline
Tech.Exp.2.Klasse
LVF-Team

Beiträge: 7.699
Registriert seit: Mar 2006

LV 2016-18 prof.
1995
DE

01108
Deutschland
Pausieren von parallel ablaufenden Producer/Consumer Schleifen
' schrieb:Da fällt mir gerade ein:
Auch wenn die Prozesskette zu langsam ist, muss sich Prozess 1 eigentlich um gar nichts kümmern: Einfach in die Queue reinschreiben. Wenn die Queue bereits voll ist, wird der letzte Puffer einfach ignoriert und geht automatisch verloren.

' schrieb:Nur kleine Ergänzung: "Automatisch" geht nichts verloren. Man muß zum Reinschreiben schon die Funktion "Element einfügen (verlustbehaftet)" verwenden und nicht die ansonsten übliche Funktion "Element einfügen"

Und mir fällt jetzt beim Lesen ein paar Tage später noch was ein:
Man muß gar keine Daten wegwerfen. Erzeuger- und Verbraucherschleife synchronisieren sich immer, ganz gleich welche von beiden schneller ist. Die langsamere der beiden Schleifen bestimmt den Takt. Man muß zum Hineinschreiben nicht das VI "Verlustbehaftet" nehmen und Daten verloren gehen lassen.

Verbraucher ist schneller: In der Verbraucherschleife wartet die Funktion "Element entfernen" immer solange, bis wieder ein Element im Puffer ist. (genügend großes Timeout vorausgesetzt)

Erzeuger ist schneller: Die Puffer läuft allmählich voll. Wenn er voll ist, dann wartet die Funktion "Element hinzufügen" so lange, bis wieder Platz für 1 Element ist. (genügend großes Timeout vorausgesetzt)

Natürlich kann es da trotzdem Probleme geben. Eine kontinuierliche DAQ-Datenerfassung läßt sich z.B. nicht durch Anhalten der Schleife stoppen.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
21.06.2010, 18:56
Beitrag #13

dimitri84 Offline
Astronaut
*****


Beiträge: 1.496
Registriert seit: Aug 2009

2020 Developer Suite
2009
DE_EN

53562
Deutschland
Pausieren von parallel ablaufenden Producer/Consumer Schleifen
' schrieb:Natürlich kann es da trotzdem Probleme geben. Eine kontinuierliche DAQ-Datenerfassung läßt sich z.B. nicht durch Anhalten der Schleife stoppen.
Eben, eine Lösung ist das nicht, denn dann läuft der Kartenpuffer ganz schnell voll.

„Sag nicht alles, was du weißt, aber wisse immer, was du sagst.“ (Matthias Claudius)
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
21.06.2010, 19:30 (Dieser Beitrag wurde zuletzt bearbeitet: 22.06.2010 07:12 von Lucki.)
Beitrag #14

Lucki Offline
Tech.Exp.2.Klasse
LVF-Team

Beiträge: 7.699
Registriert seit: Mar 2006

LV 2016-18 prof.
1995
DE

01108
Deutschland
Pausieren von parallel ablaufenden Producer/Consumer Schleifen
' schrieb:Eben, eine Lösung ist das nicht, denn dann läuft der Kartenpuffer ganz schnell voll.

Kann er ja. Was ich rüberbringen wollte war, daß der Queuepuffer nicht über läuft und von daher keine Daten verloren gehen.

Aleph1 schreibt nicht, wie er die Daten aufnimmt. Wenn die Daten softwaremäßig oder nicht kontinuierlich getriggert werden dann ist das Anhalten der Datenerfassung kein Problem. Wenn aber die Erfasung kontinuierlich mit einer DAQmx NI-Karte mit internem Takt erfolgt, dann läuft die ganze Datenerfassung autark ab und kann nicht so einfach zum Pausieren gebracht werden. Das wollte ich mit dem zitierten Satz andeuten.

Wir wissen auch sonst nichts über den Hintergrund des Problems, also z.B. nicht, ob das Pausieren der Datenerfassung oder das Wegwerfen von Daten überhaupt mit der Aufgabenstellung kompatibel ist. Somit bleiben alle Antworten und Lösungsvorschläge, und so auch die meinigen, letztlich spekulativ.

Und wenn ich weiter spekulieren darf: Die vermeintliche Langsamkeit der Datenverarbeitung gegenüber der Datenerfassung hat ihre Ursache fast immer in behebbaren Anfängerfehlern, z.B. Einzelverarbeitung jedes neuen Datenpunktes, vor allem aber in irrsinnig hohen Updateraten in Diagrammen und Anzeigen.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
24.06.2010, 11:36 (Dieser Beitrag wurde zuletzt bearbeitet: 24.06.2010 11:58 von Aleph1.)
Beitrag #15

Aleph1 Offline
LVF-Gelegenheitsschreiber
**


Beiträge: 51
Registriert seit: Sep 2005

7.1 + 8.6.1
2005
de_en

69120
Deutschland
Pausieren von parallel ablaufenden Producer/Consumer Schleifen
Servus,

Zitat:Aleph1 schreibt nicht, wie er die Daten aufnimmt. Wenn die Daten softwaremäßig oder nicht kontinuierlich getriggert werden dann ist das Anhalten der Datenerfassung kein Problem. Wenn aber die Erfasung kontinuierlich mit einer DAQmx NI-Karte mit internem Takt erfolgt, dann läuft die ganze Datenerfassung autark ab und kann nicht so einfach zum Pausieren gebracht werden.

zum Schema der Datenaufnahem ist folgendes zu sagen:
Ich nehme einen Wellenzug mit bis zu 200.000 Einzelwerten auf. Der Start der Datenaufnahme ist getriggert und dann werden 200.000 Einzelwerte kontinuierlich eingelesen und anschließend die Datenaufnahme beendet.
Das ist dann ein Element der Queue welches weiterverabeitet werden muss. 200.000 Datenpunkte werden dabei in ca. 0.2s eingelesen, können/sollen aber auch schneller eingelesen werden (in Zukunft). Diese 0.2s geben mir die Zeitauflösung meines abschließenden Messergebnisses.
(Zur Info: Ich arbeite auf dem Gebiet der Diodenlaserspektroskopie und brauche einfach diese Datenmengen um vernünftige Ergebnisse zu erhalten.)

Zitat:Und wenn ich weiter spekulieren darf: Die vermeintliche Langsamkeit der Datenverarbeitung gegenüber der Datenerfassung hat ihre Ursache fast immer in behebbaren Anfängerfehlern, z.B. Einzelverarbeitung jedes neuen Datenpunktes, vor allem aber in irrsinnig hohen Updateraten in Diagrammen und Anzeigen.

Aus diesem Queueelement wird im zweiten Prozess die Autokorrelation berechnet. Das dauert einfach seine Zeit und ich denke dass diese Berechnung der Flaschenhals ist. Je länger der Wellenzug ist, desto länger benötigt die Autokorrelation zur Berechnung, allerdings sinkt auch die Zeitauflösung (also die Zeitdauer des Gesamtwellenzuges erhöht sich).
Auf Diagramme kann ich weitestgehend verzichten, allerdings ist das ein guter Punkt den ich vollkommen vergessen hatte.

Zitat:Wir wissen auch sonst nichts über den Hintergrund des Problems, also z.B. nicht, ob das Pausieren der Datenerfassung oder das Wegwerfen von Daten überhaupt mit der Aufgabenstellung kompatibel ist. Somit bleiben alle Antworten und Lösungsvorschläge, und so auch die meinigen, letztlich spekulativ.

Das Pausieren bzw. Wegwerfen einzelner Daten (also Gesamtwellenzüge) kann bei genügend hoher Zeitauflösung des Messergebnisses (0.2s und besser) in Kauf genommen werden, ist aber stark von der meiner aktuellen Anwendung und Fragestellung abhängig.

Ich seh schon, das ist mit mehr Detailfragen behaftet, als ich eigentlich dachte.
Aber ihr helft mir sehr weiter.

Gruß
Karl
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
24.06.2010, 11:48 (Dieser Beitrag wurde zuletzt bearbeitet: 24.06.2010 11:49 von eg.)
Beitrag #16

eg Offline
LVF-SeniorMod


Beiträge: 3.868
Registriert seit: Nov 2005

2016
2003
kA

66111
Deutschland
Pausieren von parallel ablaufenden Producer/Consumer Schleifen
Ich würde die Mittelung der Daten (Kompression) direkt im ersten Prozess ausführen und die Daten "dezimiert" weitergeben, somit sollte die Senke (Abspeicherung) schneller laufen. Die Abspeicherung würde ich nicht zeilenweise ausführen, sondern blockweise (dann läuft es IMHO besser).

Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
24.06.2010, 12:02
Beitrag #17

Aleph1 Offline
LVF-Gelegenheitsschreiber
**


Beiträge: 51
Registriert seit: Sep 2005

7.1 + 8.6.1
2005
de_en

69120
Deutschland
Pausieren von parallel ablaufenden Producer/Consumer Schleifen
Dann verliere ich aber massiv an Zeitauflösung. Dann nehm ich lieber den kleineren Flaschenhals der Datenspeicherung in Kauf.
Die Daten werden allerdings im Binärformat abgespeichert, daher ist Zeilen oder Spaltenweise abspeicherung irrelevant.

Gruß
Karl
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
24.06.2010, 12:03
Beitrag #18

dimitri84 Offline
Astronaut
*****


Beiträge: 1.496
Registriert seit: Aug 2009

2020 Developer Suite
2009
DE_EN

53562
Deutschland
Pausieren von parallel ablaufenden Producer/Consumer Schleifen
So viel geschrieben und doch so wenig preisgegeben. Welche Karte benutzt du? Eine von NI oder einem Drittanbieter? Bei 1MHz Sampling-Rate kann man Softwaretakt wohl ausschließen ...

Also holst du Datenpakete à 200.000 Samples ab?

' schrieb:Das ist dann ein Element der Queue welches weiterverabeitet werden muss. 200.000 Datenpunkte werden dabei in ca. 0.2s eingelesen, können/sollen aber auch schneller eingelesen werden (in Zukunft). Diese 0.2s geben mir die Zeitauflösung meines abschließenden Messergebnisses.
Circa 0.2s?! Wieso circa?

Zitat:Wegwerfen einzelner Daten (also Gesamtwellenzüge) kann bei genügend hoher Zeitauflösung des Messergebnisses (0.2s und besser) in Kauf genommen werden, ist aber stark von der meiner aktuellen Anwendung und Fragestellung abhängig.
Unter zeitlicher Auflösung verstehe ich das dt. Bei dir 1/1Mhz.

„Sag nicht alles, was du weißt, aber wisse immer, was du sagst.“ (Matthias Claudius)
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
24.06.2010, 12:15
Beitrag #19

eg Offline
LVF-SeniorMod


Beiträge: 3.868
Registriert seit: Nov 2005

2016
2003
kA

66111
Deutschland
Pausieren von parallel ablaufenden Producer/Consumer Schleifen
' schrieb:Dann verliere ich aber massiv an Zeitauflösung. Dann nehm ich lieber den kleineren Flaschenhals der Datenspeicherung in Kauf.
Ok, dann hilft ein stärkerer PC, Postprocessing oder verteilte Anwendung.

' schrieb:Die Daten werden allerdings im Binärformat abgespeichert, daher ist Zeilen oder Spaltenweise abspeicherung irrelevant.
Ich habe nur formell ausgesagt, also dann binäre Blöcke und nicht einzelne Pakete.

Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
24.06.2010, 12:38
Beitrag #20

Aleph1 Offline
LVF-Gelegenheitsschreiber
**


Beiträge: 51
Registriert seit: Sep 2005

7.1 + 8.6.1
2005
de_en

69120
Deutschland
Pausieren von parallel ablaufenden Producer/Consumer Schleifen
Servus,

@dimitry84
Zitat:Welche Karte benutzt du? Eine von NI oder einem Drittanbieter?
Ja, ich hab eine Karte von NI drin, bzw. sind alle Karten die wir verwenden (applikationsabhängig) von NI. Nagel mich jetzt nicht fest welche genau, ich bin grad unterwegs und hab die genaue Bezeichnung grad net parrat.
Zitat:Also holst du Datenpakete à 200.000 Samples ab?
Ja, genau.
Zitat:Circa 0.2s?! Wieso circa?
Ja, sind dann schon ganu 0.2s. Sorry für die unklare Ausdrucksweise.
Zitat:Unter zeitlicher Auflösung verstehe ich das dt. Bei dir 1/1Mhz.
Das ist die zeitliche Auflösung meines Datensamplings, also das dt, wie du schon sagst. Die zeitliche Auflösung der Messung (meine Zeitreihe) sind die 0.2s (Zeitdauer des Wellenzuges). Ein Wert der Zeitreihe setzt sich aus 200.000 Datenpunkten zusammen bzw. wird aus diesen Punkten berechnet.

@eg
Zitat:Dann verliere ich aber massiv an Zeitauflösung. Dann nehm ich lieber den kleineren Flaschenhals der Datenspeicherung in Kauf.
Zitat: Ok, dann hilft ein stärkerer PC, Postprocessing oder verteilte Anwendung.
Ja, genau, deswegen auch die Verteilung auf mehrere Prozessoren. Das scheint mir zunächst mal der einfachste Zugang.
Zitat:Ich habe nur formell ausgesagt, also dann binäre Blöcke und nicht einzelne Pakete.
Ah OK, dann ist das klar.

Gruß
Karl
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Antwort schreiben 


Möglicherweise verwandte Themen...
Themen Verfasser Antworten Views Letzter Beitrag
Rainbow Programm pausieren Kaya 14 8.291 11.09.2023 12:15
Letzter Beitrag: GerdW
  Queue verwendung in komplexer Producer/Consumer Abhängigkeit Ksanto 8 5.674 03.04.2017 20:14
Letzter Beitrag: Ksanto
  2 Schleifen parallel bedienen HTL_HL 3 4.386 12.02.2016 13:05
Letzter Beitrag: Lucki
  Mehrere Schleifen parallel ausführen! houss 7 12.912 06.08.2013 14:41
Letzter Beitrag: houss
  Producer/Consumer? Neon88 2 5.143 12.09.2012 17:07
Letzter Beitrag: Neon88
  VI pausieren ohne Blockdiagramm anzuzeigen 052ftemu 4 4.931 27.06.2012 16:34
Letzter Beitrag: 052ftemu

Gehe zu: