RealTimeChart mit TeeChart und großer Datenmenge

[Ro90]

Hallo,

ich bin Anfänger in Delphi, ich programmiere eigentlich SPS-Automatisierungssysteme, habe aber immer Visualisierungen in Delphi erstellt.

Ich habe jetzt eine Aufgabe bekommen eine Art Plotter für eine Industrieanlage zu Programmieren.

Ich bekomme ca. alle 10-50ms von einer SPS-Steuerung 16 Real Werte.
Dies habe ich mittels einem Thread auch schon schön hinbekommen dass alle Signale ziemlich schnell in Delphi ankommen.

Ich soll jetzt mittels TeeChart einen Plotter erstellen der mir diese Werte extrem schnell für 24h aufzeichnet,
die alten werte werden dann verworfen.

Meine Rechnung:
16 Werte alle 10ms einen Eintrag währen 1600 Werte pro Sekunde.
Weiters währen dass dann in 24h 138.240.000 Werte.
Kling für mich ein wenig unmöglich dies schnell zu verarbeiten.

alle 50ms einen Eintrag ins Chart wären auch noch akzeptabel,
dabei währen es aber in 24h auch noch 27.648.000 Einträge.

Aber ich wollte es dann einmal probieren es vielleicht eine Stunde hinzubekommen.

Zuerst habe ich es mittels TeeChart (RealTimeCharting mit Series AfterAdd usw.) versucht,
aber erfolglos weil dies sehr schnell sehr langsam wird.

Dann habe ich versucht einen Array mit 1.000.000 Werten ins Chart zu laden,
dies funktionierte dann auch in unglaublich schneller Zeit.
Jedoch müsste ich den Array als Ringpuffer realisieren:

Delphi-Quellcode:

// Array als Ringpuffer (alten Wert löschen, alles nachschieben)
procedure Thread_Array.movedArray(var temparray: array of double);
var i: integer;
begin
  for i := 0 to Length(temparray)-2 do temparray[i] := temparray[i+1];
end;

(vielen dank, diesen Code habe ich auch von hier )

aber bei 1.000.000 Werte ist dies dann auch ziemlich langsam, obwohl ich dies in einem Thread ausführe.
Klingt für mich auch logisch weil 999.999 Werte zu verschieben sicher kein klax ist.

Hat jemand eine Idee wie diese Aufgabe zu realisiere währe, ich habe leider wenig Erfahrungen mit TeeChart.
Ich habe mich auch schon ein wenig mittels Queue beschäftigt, aber ich weiß nicht ob dies der richtige Ansatz ist.

Und Entschuldigung wenn ich einen kapitalen Denkfehler habe, aber ich habe bisher nur einfache Projekte gemacht.

Vielen dank im Vorraus.

[Chemiker]

Hallo Ro90,

man sollte zuerst klären, ob es Sinn macht 138 Mio. Werte in einem TeeChart unterzubringen. Was will der Benutzer sehen? Man könnte um die Masse an Werte zu verringern die dargestellt werden sollen, mittels eines Ringpuffers einen Durchschnittswert berechnen, sagen wir alle 1000 Werte einen Durchschnitt berechnen und diesen Wert in einem TeeChart übertragen.

Bis bald Chemiker

[Perlsau]

Davon abgesehen arbeiten die gängigen Bildschirme mit einer Frequenz zwischen 50 und 70 Hertz. Mehr als 70 Veränderungen pro Sekunde können daher sowieso nicht dargestellt werden, weil der Bildschirm wird bei 70 Hz eben nur 70mal neu aufgebaut. Und mehr an Veränderung bzw. noch schnellere Veränderungen kann das Auge auch gar nicht wahrnehmen, die Grenze liegt weit unterhalb 70 Hz. Ab 20 bis 24 Bilder pro Sekunde nimmt das menschliche Auge die aufeinanderfolgenden Bilder als kontinuierlichen Fluß dar, Film genannt.

Im Grunde handelt sich sich beim dem, was der TE vor hat, um ein Oszilloskop. Darüber hab ich, soweit ich mich noch erinnere, mal gelesen, daß die PC-Oszilloskope mit einer Verschiebung des Bildschirminhalts arbeiten. Das funktioniert mit BitBlt:

Als Bit blit (für Bit Block Image Transfer; auch als BitBlt oder ähnlich bezeichnet für bit block transfer) bezeichnet man eine Computeroperation, die für das schnelle Kopieren und Verschieben von Speicherinhalten (Blitting) zuständig ist. Bit blit kann entweder als Softwareprozedur oder als Funktion einer hardwarebasierten Grafikausgabe (Grafikkarte, -Chip oder Chipsatz) implementiert werden; im Fall eines dedizierten Chips bezeichnet man diesen auch als Blitter. Bit Blit geht auf die sogenannte RasterOp-Spezifikation von Newman und Sproull zurück, eine Funktion zum bitweisen Kopieren von Speicherblöcken, die aber noch stark begrenzt war. Eine Hardware-Implementierung der RasterOp-Funktion wurde von VLSI Technology 1986 vorgestellt. Dieser Chip hatte keine DMA-Funktion und konnte daher den Hauptprozessor kaum entlasten. Quelle

Man zeichnet dann eigentlich nur noch auf die freigewordene Fläche. Wie das zu implementieren ist, weiß ich jetzt nicht aus dem Stegreif zu beantworten, dürfte sich aber vielfach im Netz finden lassen. Mit Sicherheit gibt es auch entsprechende Komponenten dafür. Der Suchbegriff Oszilloskop bzw. oszilloscope in Verbindung mit dem Suchwort Delphi wird sicherlich einiges zutage fördern.

[Dejan Vu]

Wenn dein Bildschirm eine horizontale Auflösung von -sagen wir- 2000 Pixeln hat, dann macht es keinen Sinn, mehr als 2000 Punkte (also genauer: verschiedene X-Koordinaten) darzustellen. Imho kann man das ohne Probleme auch halbieren.

Du musst also nur 1000 Punkte aus dem darzustellenden Intervall vorhalten. Und wenn das immer die letzten X Sekunden/Minuten/Stunden sind, dann verschieben sich alle 1000 Punkte immer mal wieder, nämlich genau alle X/1000 Sekunden/Minuten/Stunden um eine Stelle nach links.

Wie Perlsau schon erwähnte: Es gibt mit Sicherheit fertige Lösungen.

[4dk2]

Komme auch aus dem SPS Sektor,

Hab auch schon diverse sachen in den Teecharts angezeigt, und es ist dafür auch gut geeignet.
Aber die Frage ist ob du wirklich alle Werte anzeigen musst, oder ob nicht z.b. ein gemittelter Wert von 1 Sekunde ausreicht.
Als Tip noch.
Die Serien haben BeginUpdate /Endupdate, was das zeichnen verkürzt.
Du kannst auch einen Ringpuffer realisieren indem du immer nur einzelne Punkte (0..n) aus der Serie entfernst, danach dann die neuen hinzufügst.

[PMM]

24 Stunden aufzeichnen wäre ja nicht zwangsläufig 24h anzeigen.
Was die Verdichtung angeht: Wie wäre es mit Min/Max/Mittel über einen geeignet gewählten Zeitabschnitt. Kann man auch gut darstellen (ergibt so einen "pelzige" Graphen). Er Vorteil ist, dass Ausreißer nicht unterdrückt werden (ist oft sehr wichtig).
PMM