Chart-Komponente die 1000 Werte / sec verträgt

[DelphiManiac]

Hallo,

ich habe folgende Anforderung und hoffe ihr könnt mir helfen.
Ich habe ein Messgerät, dass mir jede ms einen Wert übermittelt, diesen will ich in einer Plot / Graph Komponente darstellen.
Jetzt meine Frage, kennt ihr Graphen die damit umgehen können?

Gruß

[himitsu]

Windows ist als Nicht-Echtzeitsystem eh nicht dafür geeignet genau aller 'ner MS was zu empfangen.

Warum willst du unbedingt ALL diese Daten live anzeigen?
Angucken kann sich das sowieso keiner.


Ich hab's jetzt nicht ganz sicher im Kopf, aber gaub wir laden so 100000 Werte in knapp 2-3 Sekunden da rein, wobei das Chart schnell ist, aber die DB braucht etwas, um diese Datensätze zu liefern. (z.B. 10 Datasetzt, á je 10080 Datensätze)

[Daniel]

Wie soll die Grafik denn aussehen? Ich meine - man wird ja wohl kaum in Echtzeit 1.000 Aktualisierungen pro Sekunde vornehmen wollen.

Soll die Grafik ein laufender ("scrollender") Strom an Werten sein oder addiert sich da etwas oder wird da gruppiert und summiert?

Du wirst auf jeden Fall eine Form von Zwischenverarbeitung benötigen, denn wenn Du jeden Meßwert auf nur einen Pixel legst, bist Du nach 1-2 Sekunden raus aus dem sichtbaren Bereich herkömmlicher Bildschirme.

Wenn das beispielsweise ein von rechts nach links laufender Strom werden sollte, dann könnte ich mir eine Art Array vorstellen, in dem Du die derzeit sichtbaren Werte ablegst und dann könntest Du z.B. in einem Thread, der dann ausschließlich lesend auf dieses Array zugreift, regelmäßig Deine Grafik aktualisieren.

Für die Realisierung würde ich mit TChart anfangen, alle Formen von Kantenglättung, Farbverläufen und Transparenz etc. abschalten und dann müsste das eigentlich passen - viel mehr als 10x pro Sekunde (wenn überhaupt) wirst Du das Diagramm wohl eh nicht aufbauen müssen - welcher Betrachter soll das so genau verfolgen können? Die Aktualisierungsraten könntest Du dann mit Deinem Thread steuern und einfach schauen, wie oft er das hinbekommt.

[Bummi]

Wir habe eine derartige Anforderung mit eine eigenen Komponente umgesetzt die rund 20 pro Sekunde die Darstellung aus einem per Thread gefüllten Ringpuffer aktualisiert, ein weiterer Thread schreibt die Daten aus dem Puffer in eine Datenbank.

[DelphiManiac]

Hi,

ja 1000 Messwerte pro Sekunde werden vom Messgerät rausgehauen.
Ich will im Prinzip von links nach rechts in der Zeitachse die Werte eintragen, und dass muss nicht alle 1ms geschehen (kann es ja auch bei MS gar nicht) also ich hatte
mir vorgestellt das Empfangen in eigenem Thread zu machen, der dann alle 100ms 100 Werte zum zeichnen überträgt (per synchronized Methode).
Es geht um ein Druckventil, bei dem der Druck steigt und dann ein Ventil öffnet und der Druck wieder fällt, dass passiert in 4-5sec und da werden halt so ungefähr 4000 Messwerte
auflaufen, die ich möglichst dynamisch darstellen will.

Danke.

Gruß

[DelphiManiac]

Achso,

ja der Chart, sollte automatisch skalieren, da im Prinzip nur der Verlauf wichtig ist.

[Furtbichler]

Du willst also allen Ernstes 1000 Werte pro Sekunde darstellen... Das braucht man nie und nimmer. Speichern und Aufzeichnen: Ja. Live darstellen? Kann ich mir nicht vorstellen.

[grl]

Wie bekommst du denn die Daten? USB? Ethernet? Und kannst du dir sicher sein, daß das nur 4-5 Sekunden dauert?

Denn das spannende wird bei der Geschichte nicht das Anzeigen, sondern das aufzeichnen der Daten.

Das sollte in einem möglichst kurzen und knackigen Thread passieren und bitte, bitte ohne synchronize! Damit hältst du diesen Thread nämlich an.

Ich würde in dem Aufzeichnungsthread mich nur darum kümmern, die Daten entgegenzunehmen, evtl. eine erste Prüfung durchzuführen und sie dann (wenn's echt nur 5000 Werte insgesamt werden) in einen Buffer im Speicher schreiben. Ein weiterer Thread (evtl. im Hauptthread) holt die Daten dann wenn er Zeit hat aus diesem Buffer (für den du eine Critical Section brauchst), schreibt ihn in eine Datenbank oder eine Datei und kümmert sich dann darum, die Daten anzuzeigen. Dabei bietet sich an, nur die auch Darstellbaren Punkte vorher zu bestimmen. Die einfachste Form davon wäre, immer so viele Punkte zwischen zwei anzuzeigenden auszulassen, daß du im endeffekt soviele Punkte anzeigst wie du Pixel am Schirm hast. Bei 4000 Punkten und 1024 Pixel am Schirm wär das also ca. jeder 4. Punkt - alles andere siehst du eh nicht.

Wenn du's so machst ist die Chart-Komponente weitgehend unerheblich, außer du willst dann noch irgendwelche Interaktion mit dem Betrachter, also Teile des Charts auswählen, zoomen, irgendwas dran rumrechnen oder sowas.

Schlüsselstelle ist und bleibt die Übernahme der Daten in das System und wie du sie da in einen Speicher schreibst...

Gruß
Luggi

[ChrisE]

Hi DelphiManiac,

also ich würde das Problem aufschlüsseln bzw. genauer definieren. Ich denke du brauchst die hohe Abtastrate, weil du z.B. spätere Analysen drüber laufen lassen willst - also offline - und da auch in bereich von 100 ms rein Zoomen willst um zu sehen was da los war. Aber all das betrifft ja erstmal nicht den Onlinebereich - also den Zeitpunkt des Aufnehmens. Aus meiner Sicht brauchst du Online meist nur ein Darstellung um zu sehen, dass etwas passiert und dass es so ungefähr in die Richtung geht wie man sich das vorstellt.
Dafür würde es am Anfang schon reichen nur jeden zehnten bis zwanzigsten Wert zu übergeben an das Chart. Es passiert dadurch natürlich in der Visualisierung ein undersampling - bzw. siehst du u.U. nicht jeden Peak. Aber für Online könnte das schon reichen.

Anders formuliert: Versuche Deine Anforderungen der Messtechnik / Datenverarbeitung von denen der Visualisierung getrennt zu betrachten und auch getrennt um zu setzten. Ich denke, dass könnte Dich weiter bringen.

Gruß, Chris

[Popov]

Ich habe vor einiger Zeit für eine Aufgabe paar einfache Test durchgeführt. Zwar kann man es nicht genau übertragen, aber ...

Zuerst das System: AMD 2,7 GHz. Es wurden farbige Quadrate um die 50 Pixel gezeichnet. Bei 3.000 Rechtecken hatte ich ein FPS von über 60, bei 10.000 Rechtecken hatte ich ein FPS von 30, bei 45.000 Rechtecken ein FPS von 5, das ergibt rechnerisch 225.000 Rechtecke pro Sekunde.

Allerdings fanden zwischendurch noch paar Berechnungen statt, alles lief im Rahmen des normalen Programms statt. Es war also keine reine Schleife.