erhöhte CPU load bei längerer Laufzeit von XY Graph

Hi Leute,

Ich lese über die serielle Schnittstelle Daten mit einer Datenrate von grösser oder gleich 100 ms aus. Diese Daten möchte ich in einem Graphen darstellen. Da sie nicht mit dem gleichen zeitlichen Abstand kommen benutze ich einen XY Graphen der als y Achse die Zeit (HH:MMS / DD:MM:YY) angibt.

Das alles würde eigentlich wunderbar funktionieren nur steigt die CPU Load langsam an. Irgendwann bin ich dann bei 100 % und es werden nicht mehr alle Daten von der seriellen Schnittstelle empfangen.

Wahrscheinlich hängt das alles damit zusammen das es für mich wichtig ist alle Daten über den ganzen Zeitraum im Graphen darzustellen. Es kann sein das es bis zu 500.000 Punkte oder mehr werden. (Laufzeiten zum Teil über 2 Wochen)

Nun meine Fragen:
- Hängt der ganze Anstieg mit der Grössenordnung der Daten zusammen?
Also muss für jeden Punkt der neu dazukommt nochmal alles berechnet werden?
- Ist das ganze überhaupt realisierbar?
- Oder ist der Rechner einfach zu schwach dafür?

Für mich ist es wichtig das ich den Graphen, wann immer ich will, ansehen kann um festzustellen ob alles noch richtig läuft bzw. am Ende die kompletten Daten über den gesamter Zeitbereich zu sehen.

Im Anhang findet ihr ein vereinfachte Version von dem Graphen wie er ausschauen sollte.

Smooth Update ist deaktiviert / die X Achse wird autoscaliert <- frisst leider auch einiges an CPU Leistung

Benutzte SW: LabVIEW 8 / Windows 2000
Benutzte HW: P4@1,5 GHz, 512 MB RAM, Matrix Millenium G550 AGP @32MB DDR

MFG E.O.

Das Problem liegt an der Anzahl der Daten!
Du kannst damit rechnen, dass pro angezeigtem Wert dreimal der gleiche Speicherbereich allokiert wird (2 x von Windows, wenn du die Daten anzeigen laesst!)!
LabVIEW benoetigt dazu noch kontinuierlichen Speicher, d.h. wenns an die Grenzen geht, muss der ganze Speicherbereich wo LV liegt umkopiert werden -> daher der Anstieg der CPU Last -> ich habe 1GB Speicher im PC und bemerke ebenfalls einen deutlichen Anstieg der CPU Last -> dieser Effekt tritt auch dann ein, wenn Windows beginnt, Daten in den virtuellen Arbeitsspeicher auszulagern!

Warum willst dir ueberhaupt die Daten ueber diese Zeitspanne anzeigen lassen?! Waere es nicht sinnvoller die Daten in ein File zu streamen (Binaer) und diese dann bei gegebener Zeit auszulesen und als Anzeige lediglich ein Chart zu nehmen?!

Eine andere Moeglichkeit waere noch, was ich aber lediglich als Verzoegerung sehen wuerde, dass du Timed Loops verwendest und dementsprechend die Prioritaeten vergibst! Sprich Anzeige von Erfassung aufzutrennen und dadurch die serielle Erfassung immer gewaehrleistest und die Anzeige dann, wenn Ressourcen zur Verfuegung stehen...

Das ganze ist als eine Art Empfänger Testsystem gedacht. Falls es zu ein Fehler in dem Testobjekt kommt werden die Daten auf dem Graphen angezeigt und können gleich analysiert werden ohne das der komplette Versuch durchgeführt werden muss. Auf der X Achse wird die Zeitdifferenz zwischen zwei Paketen angezeigt. Falls dort einmal eine längere Zeit eine 0 kommt hat der Empfänger ausgesetzt (=Fehler). Die kompletten Daten werden parallel dazu in eine Logfile geschrieben.
An ein Chart hätte ich auch schon gedacht aber ist es nicht so das in einem Chart die Daten nur mit gleichbleibenden Zeitabstand angezeigt werden können?

Würde es gehen wenn ich die Daten wie du gesagt hast binär in eine datei schreibe und den Graph nach einer gewissen Zeitspanne (alle paar Minuten) anzeigen lasse? Bzw. einen Button einbaue mit dem das Chart abgefragt wird?

Hab leider noch net viel LabVIEW Erfahrung und in Richtung Binäre Speicherung der Daten hab ich noch nie etwas gemacht.
Aber wie sagt man so schön einmal ist immer das erste mal

Ok hab das Problem gelöst. Vielen Dank für deine Anregung freedive.
Ich speicher die Daten die ich Anzeigen möchte als file auf der Festplatte ab. Per Knopfdruck kann ich wann immer ich will den Graphen aktualisieren. Somit bleibt die CPU Leistung konstant bis auf den einen kurzen Augenblick wo ich die File nebenbei in den Graphen lad.

MFG
E.O.