Chart-Komponente die 1000 Werte / sec verträgt

[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.

[EWeiss]

Meines erachtens sollte das mit OpenGl / DirectX doch ohne weiteres möglich sein.
Nur eine komponente dafür kenn ich nicht.

gruss

[Jens01]

Sowas? Oder hier.

[Medium]

Das Zeichnen selbst ist hier wirklich weniger der Knackpunkt. Eher die Vorstufe: Was übergebe ich an "was auch immer nachher zeichnet", bzw. wie viel davon, und ist das sinnvoll. Eine 3D API würde ich dafür jetzt allerdings eher nicht in den Raum werfen, für den putzigen Unterschied den das machen dürfte (zumal man an ganz anderen Stellen genau so ineffiziente Dinge tun könnte, da sie halt gleich zu handhaben wären (Speicherung, Übertragungsweg, Puffer füllen, etc.)) wäre das den doch nicht ganz kleinen Mehraufwand kaum wert (vor allem die Lernerei wenn man da noch nie was mit gemacht hat).

Erfahrungsgemäß ist es fast immer sehr sinnvoll, wirklich auch nur die Daten in einen Darstellungsmechanismus zu füttern, die tatsächlich angezeigt werden (können). Wie die Daten in den PC kommen, und wie sie dort gespeichert sind ist allein für's zeichnen zweitrangig. Man könnte eine Vermittlerschicht einführen, die berechnet für was für einen Zeitraum wie viele Werte auf wie viele Zielpixel gebracht werden müssen, und diese gräbt dann die nötigen Werte aus dem Datenbestand und reicht sie an ein Chart oder was auch immer weiter. Entsprechend dynamisch aufgebaut ist damit auch zoomen und scrollen effizient möglich denke ich.

Ich glaub aber immer noch, dass die echte Schwierigkeit das Aufzeichnen wird.

[himitsu]

Im Delphi 7 gibt es bei mir 2 ActiveX-Chart-Komponenten
und ab D2007 liegt ein einfaches TChart bei.

Da sollte es auch so schon Einiges zum ausprobieren geben.

[shmia]

Zitat von ChrisE:

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.

Das halte ich auch für den richtigen Ansatz.
Ich würde eine Klasse erzeugen um die Samples zu verarbeiten.
Diese Klasse bekommt als Input die ~5000-7000 Samples.
Als Output werden vorverarbeitete Daten erzeugt, die dann stressfrei angezeigt werden können.
Wenn z.B. der Oversampling-Faktor = 100 ist, dann werden immer 100 Samples aus dem Input zu einem Wert des Outputs (Durchschnitt bilden).
Desweiteren wird gleichzeitig noch der Minimum- und der Maximumwert berechnet.

Diese Daten (Durchschnitt, Minimum und Maximum) werden dann mit verschiedenen Farben zur Anzeige gebracht.
Wenn man mag kann man auch noch gleich den Median berechnen.

Durch diese Vorverdichtung der Daten (einstellbar über den OversamplingFaktor) kann man die Datenmenge immer so reduzieren, dass man sie ohne das System zu überfordern anzeigen kann.