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!
13.05.2008, 09:58 (Dieser Beitrag wurde zuletzt bearbeitet: 13.05.2008 09:59 von m0n0g0n.)
ich hab wiedermal ein LabVIEW problem und bitte euch um eure hilfe.
Es geht um folgendes:
Ich möchte über lange Zeiträume (24h) kontinulierlich Messwerte erfassen. Des weiteren sollen diese Messwerte in einem Chart dargestellt werden und wärend der laufzeit einsehbar sein. Das chart besitzt ja einen scrollbalken mit dem man sich die Werte in der history ansehen kann. Das problem ist, dass die History größe nicht ausreicht.
Als lösung hab ich mir folgendes überlegt:
Ich erfasse immer 500 samples (als waveform) und hänge diese an bereits ältere samples an (mit apped waveforms). Ich hab also ein schieberegister in einer whileschleife welches die bissher erfassen samples beinhaltet.
Wenn ich nun diese (ständig wachsende) waveform an mein chart übergebe dann kann ich immer alle messwerte einsehen. Die property node "histroy" des charts sagt, dass sie immer nur 1 element beinhaltet (das mal so nebenbei).
Nun das problem:
Da die größe meines schieberegisters kontinuierlich wächst, wird die ganze software immer langsamer. Hat jemand einen lösungsvorschlag?
Des weitere sagt mir der taskmanager das die cpu auslastung wärend der laufzeit ca. 90% beträgt. Wie kann man dies reduzieren? liegt das am schieberegister?
Anbei befindet sich noch ein screenshot meiner while schleifen.
Hallo,
ich würd die Daten nicht direkt anzeigen sondern in ne Datei wegspeichern.
Wenn du sie dann anschauen möchtest, kanst du sie in nem Anderen Programmreinladen ohne das erste zu stören.
Vorteil wäre auch das bei einem Systemabsturtz oder Stromausfall nicht alle messungen verloren wären.
Grüße
Achimedes
Wer Rechtschreibfehler findet .... darf sie behalten.
' schrieb:Hallo,
ich würd die Daten nicht direkt anzeigen sondern in ne Datei wegspeichern.
Wenn du sie dann anschauen möchtest, kanst du sie in nem Anderen Programmreinladen ohne das erste zu stören.
Vorteil wäre auch das bei einem Systemabsturtz oder Stromausfall nicht alle messungen verloren wären.
Grüße
Achimedes
Hm, und wenn man beides machen möchte? Sprich die daten zwecks sicherung wegspeichern und gleichzeitig wärend der laufzeit der messung einsehen?
' schrieb:Hm, und wenn man beides machen möchte? Sprich die daten zwecks sicherung wegspeichern und gleichzeitig wärend der laufzeit der messung einsehen?
Kann man schon machen.
Kommt halt auf die Datenmenge an. Irgendwann läuft halt dein Speicher voll und das ganze System wird langsam.
Was ich noch in deinem Programm gesehen habe:
Du hast in keiner Schleife ne Wartezeit. Das heist der Prozessor wird an den anschlag gefahren.
Mach ne kleine Wartezeit in die schleifen und schon wird der Proz nicht mehr so belastet.
Wer Rechtschreibfehler findet .... darf sie behalten.
13.05.2008, 14:36 (Dieser Beitrag wurde zuletzt bearbeitet: 13.05.2008 14:39 von m0n0g0n.)
' schrieb:Kann man schon machen.
Kommt halt auf die Datenmenge an. Irgendwann läuft halt dein Speicher voll und das ganze System wird langsam.
Was ich noch in deinem Programm gesehen habe:
Du hast in keiner Schleife ne Wartezeit. Das heist der Prozessor wird an den anschlag gefahren.
Mach ne kleine Wartezeit in die schleifen und schon wird der Proz nicht mehr so belastet.
Hm, also ich hab in jeder schleife eine verzögerung.
Die obere linke schleife ist für die datenerfassung zuständig, in ihr befindet sich das DAQmx Read VI. Diese stoppt doch die schleife solange bis die messwerte vorliegen, oder? Ich hab hier irgendwo im forum gelesen, dass man DAQmx Read und eine verzögerung in einer while schleife nicht kombinieren sollte! Weil es erstens sinnlos ist da read eh wartet und ausserdem kann dies irgendwie zu problemem führen.. bin ich da falsch informiert?
Die untere schleife hat ja auch eine indirekte verzögerung durch das Melder VI. Dort wird solange gewartet bis meine Messwerte vorliegen, bzw. bis meine obere schleife eine Meldung gesendet hat. Das ist doch ausreichend odeR? wozu noch eine extra verzögerung?
Und die dritte rechte schleife mit der ereignisstruktur hat auch eine verzögerung. Diese 100 ms am timing anschluss der struktur sorgen doch dafür odeR? oder sollte man noch eine extra verzögerung einbauen?
mfg
EDIT: Ahja, noch eine frage.. ist mein grundaufbau überhaupt sinnvoll mit den drei while schleifen? Hatte das früher alles in einer drin.
' schrieb:Hm, also ich hab in jeder schleife eine verzögerung.
Die obere linke schleife ist für die datenerfassung zuständig, in ihr befindet sich das DAQmx Read VI. Diese stoppt doch die schleife solange bis die messwerte vorliegen, oder? Ich hab hier irgendwo im forum gelesen, dass man DAQmx Read und eine verzögerung in einer while schleife nicht kombinieren sollte! Weil es erstens sinnlos ist da read eh wartet und ausserdem kann dies irgendwie zu problemem führen.. bin ich da falsch informiert?
Weiß ich nicht.
Vielleicht je nach messung.
Wenn du je schleife misst verzögert sich natürlich die messerei umdie Wartezeit es sei denndie Messung ist so konfiguruert das die Karte im hintergrund eh immer mit misst und du nur die daten abholst.
Zitat:Die untere schleife hat ja auch eine indirekte verzögerung durch das Melder VI. Dort wird solange gewartet bis meine Messwerte vorliegen, bzw. bis meine obere schleife eine Meldung gesendet hat. Das ist doch ausreichend odeR? wozu noch eine extra verzögerung?
Die messschleife läuft auf jedenfall volle pulle und somit die anzeigeschleife ja auch.
Zitat:Und die dritte rechte schleife mit der ereignisstruktur hat auch eine verzögerung. Diese 100 ms am timing anschluss der struktur sorgen doch dafür odeR? oder sollte man noch eine extra verzögerung einbauen?
Ja.
Je nach ereignissen die da alles ausgewertet werden.
Zitat:EDIT: Ahja, noch eine frage.. ist mein grundaufbau überhaupt sinnvoll mit den drei while schleifen? Hatte das früher alles in einer drin.
Ich hab die ereignissschleife auch immer in ner separaten schleife.
Bei der anzeigeschleife bin ich mir nicht so ganz sicher weil du sie ja eh mit jeden neueun messwerten wieder neu beschreibst kannst du dir die denke ich spaaren.
Du könntest noch versuchen den DAQ assi rauszuschmeissen und gegen normalen cod ersetzt.
Rechtsklick "NI-DAQmx code erzeugen"
Dann kannst du auch die Konfiguration aus der schleife nehmen.
Grüße
Achimedes
Wer Rechtschreibfehler findet .... darf sie behalten.
' schrieb:Weiß ich nicht.
Vielleicht je nach messung.
Wenn du je schleife misst verzögert sich natürlich die messerei umdie Wartezeit es sei denndie Messung ist so konfiguruert das die Karte im hintergrund eh immer mit misst und du nur die daten abholst.
Also ich hab den DAQ assi zwar verwendet, hab das VI aber meinen bedürfnissen angepasst. Die Messung ist so konfiguriert, dass er mir kontinuierlich Daten mit 10 khz liefert. Und ich hole immer 6 Kanäle mit jeweils 500 Samples ab. Und solange wartet doch das prog oder? bis die 500 Samples komplett da sind. Reicht das nicht als verzögerung? Sollte zusätzlich noch eine eingebaut werden?
Zitat:Die messschleife läuft auf jedenfall volle pulle und somit die anzeigeschleife ja auch.
Ist das wirklich so? Wenn ich mit 10 kHz kontinuierlich abtaste und immer 500 Samples abhole, dann müsste die while schleife doch mit 20 Hz laufen oder nicht? Können bereits 20 hz die cpu bis zum anschlag ausfahren?
Zitat:Bei der anzeigeschleife bin ich mir nicht so ganz sicher weil du sie ja eh mit jeden neueun messwerten wieder neu beschreibst kannst du dir die denke ich spaaren.
Ich würde gerne die Graphenaktualliserungsrate (braucht am meisten power) unabhängig von der Abtastfrequenz gestalten. Wie ist die optimale rate? Hab hier mal was von 10 hz gelesen. Hast du ne idee wie man das unabhängig gestalten kann? Ereigniss gesteuerte datenerfassung? und dann alle n samples darstellen?
Zitat:Du könntest noch versuchen den DAQ assi rauszuschmeissen und gegen normalen cod ersetzt.
Rechtsklick "NI-DAQmx code erzeugen"
Dann kannst du auch die Konfiguration aus der schleife nehmen.
Naja, wie bereits erwähnt, hab ich ihn ja meinen bedürfnissen angepasst. Und die konfiguration wird ja nur beim ersten VI aufruf ausgeführt, also muss man die doch nicht rausnehmen oder?
Möchte Achimedes widersprechen. Es müsste langen, dass du immer auf 500 Samples wartest, da brauchst du kein zusätzliches Wait in der Schleife.
Problem sehe ich einfach im Speicher volllaufen (leider weiss ich nicht, was in deinem Mean & deinem Build Signal passiert), aber nur mal so überschlagsmäßig:
Du erfasst 6 Kanäle mit 10 Khz, die du, so wie ich verstehe, auch alle speicherst. Macht pro Kanal pro Stunde 36 Mio Datensätze -> 24 h -> 864 Mio, das dann noch mal 6, autsch, dann noch mal 8 Byte (beim Format DBL), dann sind wir bei 6*8*864=41472 Megabyte, da muss der Computer ja in die Knie gehen. Wahrscheinlich werden die Waveforms auch noch per "Build-Array" Operationen aneinander gehängt. Das ist Gift für den Hauptspeicher. LV alloziert dann dauernd neuen Speicher für das neue Array, bevor es den alten freigibt. Dabei zerstückelt der Speicher immer mehr.
Besser ist es bei größeren Datenmengen, ein Array vorher zu allozieren, wobei das bei deiner Datenmenge ebenfalls schwierig wird.
MfG, Jens
Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)
!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!
Zitat:Also ich hab den DAQ assi zwar verwendet, hab das VI aber meinen bedürfnissen angepasst. Die Messung ist so konfiguriert, dass er mir kontinuierlich Daten mit 10 khz liefert. Und ich hole immer 6 Kanäle mit jeweils 500 Samples ab. Und solange wartet doch das prog oder? bis die 500 Samples komplett da sind. Reicht das nicht als verzögerung? Sollte zusätzlich noch eine eingebaut werden?
habs mal getestet.
du hast recht. da brauchst du keine Wartezeit wehr
Zitat:Ist das wirklich so? Wenn ich mit 10 kHz kontinuierlich abtaste und immer 500 Samples abhole, dann müsste die while schleife doch mit 20 Hz laufen oder nicht? Können bereits 20 hz die cpu bis zum anschlag ausfahren?
Nö. das sollte langsam genug sein.
Zitat:Ich würde gerne die Graphenaktualliserungsrate (braucht am meisten power) unabhängig von der Abtastfrequenz gestalten. Wie ist die optimale rate? Hab hier mal was von 10 hz gelesen. Hast du ne idee wie man das unabhängig gestalten kann? Ereigniss gesteuerte datenerfassung? und dann alle n samples darstellen?
kann ich nicht wirklich was dazu sagen.
Da die Daten irgendwann mal zu viel werden würd ich versuchen die Daten nicht ständig im Speicher zu halten.
Was der Melder macht weiss ich auch nicht so genau. wenn der aber alle Daten Kopiert dann wirds wirklich kritisch.
Deshalb vieleicht doch den Graf mit in die obere schleife
Zitat:Naja, wie bereits erwähnt, hab ich ihn ja meinen bedürfnissen angepasst. Und die konfiguration wird ja nur beim ersten VI aufruf ausgeführt, also muss man die doch nicht rausnehmen oder?
Habs getestet. du hast recht.
Wer Rechtschreibfehler findet .... darf sie behalten.
' schrieb:Möchte Achimedes widersprechen. Es müsste langen, dass du immer auf 500 Samples wartest, da brauchst du kein zusätzliches Wait in der Schleife.
Ok danke.
Zitat:Problem sehe ich einfach im Speicher volllaufen (leider weiss ich nicht, was in deinem Mean & deinem Build Signal passiert), aber nur mal so überschlagsmäßig:
Das mean bildet aus den 500 Samples den Mittelwert. Und Build hängt die waveforms aneinander mit "Apped waveforms".
Zitat:Du erfasst 6 Kanäle mit 10 Khz, die du, so wie ich verstehe, auch alle speicherst. Macht pro Kanal pro Stunde 36 Mio Datensätze -> 24 h -> 864 Mio, das dann noch mal 6, autsch, dann noch mal 8 Byte (beim Format DBL), dann sind wir bei 6*8*864=41472 Megabyte, da muss der Computer ja in die Knie gehen. Wahrscheinlich werden die Waveforms auch noch per "Build-Array" Operationen aneinander gehängt. Das ist Gift für den Hauptspeicher. LV alloziert dann dauernd neuen Speicher für das neue Array, bevor es den alten freigibt. Dabei zerstückelt der Speicher immer mehr.
Ja, also ich glaube ich muss wohl das ganze programm konzept über den haufen werfen.
/
Problem mit kontinuierlicher Datenerfassung
