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 :-D )

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

[Der schöne Günther]

Schau mal hier:
http://www.teechart.net/reference/ar...CLRealtime.pdf

Dinge wie die Sortierung auszuschalten wenn man die Werte selbst schon sortiert vorliegen hat macht einen riesigen Unterschied bei großen Punktemengen. Dann halt die üblichen verdächtigen wie TFastLineSeries ohne Kantenglättung und alles, und Achsen nicht automatisch immer neuskalieren. Hat bei mir einen riesigen Unterschied gemacht.

[Ro90]

Hallo,

Erstmal vielen Dank für die informationsreichen Antworten.

Um kurz den Sinn der Software zu erklären.

Wie schon von Perlsau erwähnt wurde wird es eine Art von Oszilloskop.

Ich arbeite an in einer großen Holzindustrie mit vielen sehr alten Anlagen.

Wenn jetzt an so einer Anlage ein Fehler auftritt soll die Software dies ersichtlich machen.
Diese Fehler sind öfters nur sporadisch und die Ursachen sind durch die sehr hohe Geschwindigkeiten der Anlage sehr schwer herauszufinden.
Dies dauert dann oft tagelang bis man einen Fehler erkennt, zu 99% sind es Fehler durch Sensoren.
Sobald solch ein Fehler dann auftritt hängt ein Elektriker dann die Software an diese Anlage
und wählt bis zu 16 Signale aus z.B. Sensor, Lichtschranke, Schalter usw.

Die Software soll dann mittels Ringpuffer diese Signale festhalten
und wenn der Elektriker dann wieder Zeit hat und weiß dass der Fehler z.B um 14Uhr aufgetreten ist
scrollt er durchs Chart und kann dann sehen ob vielleicht zu diesem Zeitpunkt ein z.B Sensor ein falsches Signal gesendet hat.

Es kommt aber vor das Sensoren nur sehr kurz belegt werden (ca.50ms), und dies sollte dann auch ersichtlich sein.

Es gibt schon ähnliche Software die das ermöglicht, nur nicht mit dieser Geschwindigkeit und nicht mit solchen Funktionen die ich benötige:


ich füge noch ein Paar Bilder von meinem Projekt hinzu.

[Uwe Raabe]

Zitat:

Zitat von Ro90 (Beitrag 1324543)

und wenn der Elektriker dann wieder Zeit hat und weiß dass der Fehler z.B um 14Uhr aufgetreten ist
scrollt er durchs Chart und kann dann sehen ob vielleicht zu diesem Zeitpunkt ein z.B Sensor ein falsches Signal gesendet hat.

Dann reicht es doch, wenn du die Daten erstmal nur zwischenspeicherst. Der Elektriker scrollt dann eben nicht durch das gesamte Chart, sondern gibt lediglich den Zeitraum ein, den er sehen möchte. Das sollte doch die anzuzeigenden Daten und damit die Zeit für den Aufbau der Anzeige deutlich reduzieren.

[Ro90]

Ja das würde auch funktionieren, dass der Elektriker dann sagt ich will die Grafik von 13:55 bis 14:05 Uhr sehen.

Ich habe jedoch schon Probleme diese Daten zwischenzuspeichern,
ich habe einen dynamisches Array mit 1 Mio. Werten,
dieses in die Chart zu laden habe ich schon hinbekommen,
dies mache ich alle 10 sec und es funktioniert erstaunlicherweise sehr schnell.

Jedoch wenn dieses Array 1 Mio überschreitet muss es als Ringpuffer weiterarbeiten,
also 0 löschen und alle anderen Werte nachschieben,
dies bereitet mir die Probleme dass alles anfängt langsam zu werden.

Ich habe glaube ich die komplett falsche Lösung wie ich diese Daten zwischenspeichere.

Vielen Dank

[nahpets]

Wenn ich das recht verstehe, musst Du die Daten nicht "Live" darstellen, sondern jederzeit rückwirkend anzeigen können.

Das hieße doch, dass Du "nur" die Datenmenge entsprechend schnell irgendwie auf die Platte bekommen musst, um sie später auszugsweise per Chart darzustellen, damit "Ausreißer" sichtbar dargestellt werden können.

Wenn es für die Daten "Normalwerte" gibt und "Fehlerwerte" würde ich mir hier eine Datenbankanwendung vorstellen.

Die Daten müssten erstmal mit der entsprechenden Geschwindigkeit in die Datenbank geschrieben werden.

In der Datenbank kann man dann per Abfrage nach "Ausreißern" suchen und dann den Bereich "rundherum" (also Minuten, Sekunden... vorher und/oder nachher) anzeigen und damit ggfls. durch den Datenbestand scrollen. Hierdurch ließe sich ja dann die Entwicklung der Werte im Umfeld der "Ausreißer" darstellen.

Oder stell' ich mir das jetzt falsch vor?

[Ro90]

Ja genau nahpets,

mein Hauptproblem liegt dabei dass ich alle 10ms 16 Werte auf die Platte bringen muss.

Und nach 24 Stunden (12h währen auch akzeptabel) können die älltesten wieder weg.

Da ich wenig Erfahrung mit sowas habe fällt mir keine Lösung ein mitder ich sowas erreichen kann,
und wenn möglich sollte dann der Teil den der Elektriker sehen will ein Array sein oder in ein Array umgewandelt werden können
damit ich es schnell in das Chart bringe.

Die 'Ausreißer' sieht eben nur der Bedienmann an der Anlage und schreibt dann die Uhrzeit auf (oder drückte eine Taste).

Sobald dann der Elektriker wieder an die Anlage kommt (kann je nach Umständen auch mal einen halben Tag dauern).
Dann soll der Teil in der Datenbank oder Array oder ... noch da sein damit er diesen Teil dann in der Chart ansehen kann.

Vielen Dank

[Perlsau]

Zitat:

Zitat von Ro90 (Beitrag 1324553)

mein Hauptproblem liegt dabei dass ich alle 10ms 16 Werte auf die Platte bringen muss.

Mußt du ja gar nicht wirklich. Was du tatsächlich mußt: 1600 Werte pro Sekunde zwischenspeichern, und das ein wenig länger als es dauern würde, die Daten auf Platte bzw. in DB zu speichern. Schau mal, CD- und DVD-Brenner arbeiten ja auch nicht viel anders, obwohl hier der Schreibvorgang oft schneller ist als das "Zusammenkratzen" der zu schreibenden Daten (wenn z.B. die Quellplatte stark fragmentiert ist oder zusätzlich andere Prozesse auf die Quellplatte zugreifen): Da gibt es einen Puffer, der erst einmal bis zu einer gewissen Größe gefüllt wird, bevor er Schreibvorgang beginnt. Umgesetzt auf deine Bedürfnisse müßtest du dir einen Speicherpuffer – meinetwegen dein dynamisches Array, von dem du oben schreibst – bereitstellen, der sich ab einem gewissen Befüllungsstand selbst speichert, ob jetzt in Datei oder DB soll erstmal zweitrangig sein. Um das Verschieben beim Ringpuffern zu vermeiden (BitBlt ist dennoch sauschnell), könntest du einen zweiten Speicherpuffer einsetzen, der sich mit dem ersten abwechselt: Hat der erste seinen Sollfüllstand erreicht, biegt er die Ausgabe auf den anderen Puffer um, speichert sich selbst und leert sich anschließend. Der zweite Puffer arbeitet ebenso. Das ganze in entsprechende Threads ausgelagert sollte der hohen Geschwindigkeitsanforderung genügen ... 1600 Werte pro Sekunde sind jetzt auch nicht die Welt.

Zitat:

Zitat von Ro90 (Beitrag 1324553)

Und nach 24 Stunden (12h währen auch akzeptabel) können die älltesten wieder weg.

Außer es ist in diesem Zeitraum ein Fehler aufgetreten, der noch genauer untersucht werden muß.

Zitat:

Zitat von Ro90 (Beitrag 1324553)

Da ich wenig Erfahrung mit sowas habe fällt mir keine Lösung ein mitder ich sowas erreichen kann,
und wenn möglich sollte dann der Teil den der Elektriker sehen will ein Array sein oder in ein Array umgewandelt werden können
damit ich es schnell in das Chart bringe.

Um mich nochmal zu vergewissern: Die 1600 Signale pro Sekunde sollen nicht im laufenden Betrieb abgenommen und gespeichert werden, sondern erst dann, wenn der Elektriker mit seiner Software an der Maschine ist, nachdem ein Fehler aufgetreten ist. Oder muß der Elektriker dann doch den Zeitraum während der Produktion, in dem der Fehler auftrat, überprüfen und analysieren können? Egal wie die Antwort ausfällt, mir ist der Zwang für die hohe Geschwindigkeit der Darstellung noch immer nicht so recht klar geworden: Wenn die Signale in Echtzeit während der Produktion dargestellt werden sollen, frage ich mich natürlich, zu welchem Zweck dies erfolgen soll. Es macht ja keinen Sinn, denn die Signale müssen ja in erster Linie für die spätere Auswertung gespeichert werden. Mit dem schnellen Wechsel der Signale kann ein Beobachter, der da ab und zu mal draufschaut, doch nicht wirklich was anfangen, oder? Eine neben der Speicherung erfolgende Anzeige würde die Speicherung mehr oder weniger verzögern oder gar die kontinuierliche Speicherung der Werte während der Produktion behindern. so daß die gespeicherten Werte nicht mehr vollständig wären.

Zitat:

Zitat von Ro90 (Beitrag 1324553)

Die 'Ausreißer' sieht eben nur der Bedienmann an der Anlage und schreibt dann die Uhrzeit auf (oder drückte eine Taste).

Der Maschinenbediener muß also die ganze Zeit unbeirrt auf den Bildschirm starren? Wäre es da nicht sinnvoller, Ausreißer – das sind dann vermutlich die Fehler – gleich mit zu protokollieren bzw. im Protokoll als Ausreißer zu kennzeichnen? Tabellenfelder wären dann ein Timestamp, die Nummer des Sensors, der gemessene Wert und ein Boolean, der Auskunft darüber gibt, ob der Wert irgend einen Maximalwert überschreitet. Und beim Protokollieren bzw. beim Analysieren des Signals kann man doch auch gleich einen akkustischen Warnton einbauen, der darüber informiert, daß ein Fehler aufgetreten ist. Dieses stundenlange hochkonzentrierte Starren auf den Bildschirm hält doch kein Mensch wirklich durch und ist daher fehleranfällig.

Zitat:

Zitat von Ro90 (Beitrag 1324553)

Sobald dann der Elektriker wieder an die Anlage kommt (kann je nach Umständen auch mal einen halben Tag dauern).
Dann soll der Teil in der Datenbank oder Array oder ... noch da sein damit er diesen Teil dann in der Chart ansehen kann.

Zumindest für den Elektriker spielt die Geschwindigkeit der Darstellung dann keine Rolle mehr, denn der muß die Daten nicht in Echtzeit ablaufen sehen, um den Fehler einkreisen zu können. Er muß sich lediglich in den Daten bewegen (scrollen) können.

[nahpets]

Also nochmal, damit ich's (hoffentlich) verstehe.

Ein Maschine hat ein undefiniertes Problem.

Ein Elektriker schließt die Überwachungssoftware an und geht.

Der Bediener beobachtet die Anzeige und reagiert bei einem Ausreißer.

Hier könnte man auch ohne Datenbank auskommen.

Mal folgende Annahme:

Du kannst die Daten schnell genug sammeln.

Sagen wir, Du sammelst sie immer für eine Minute, dann kannst Du jede Minute die Daten einer Minute in eine Datei schreiben. Dateien, die älter als 24 Stunden sind werden (sporadisch) gelöscht.

Die Daten einer Minute zeigst Du für eine Minute im Chart an. Dann hat der Bediener Zeit, jede Minute nach Ausreißern zu suchen und 'ne Taste zu betätigen oder sich die Zeit aufzuschreiben. Bei der Datenmenge "live" zuzuschauen und zu reagieren, halte ich für extrem anstrengend und dürfte recht schnell zu einer Ermüdung führen, die bei einem Maschinenbediener sicherlich nicht risikofrei ist.

Wenn jetzt per Tastendruck oder Aufschreiben der Zeitpunkt des Ausreißers bekannt ist, kann sich der Elektriker zu einem späteren Zeitpunkt die Daten aus der Datei des "Ausreißerzeitpunktes" anzeigen lassen und per scrollen jeweils eine Minute vor- oder zurückscrollen.

Je nach Implementierung könnte daraus dann (eventuell) auch eine fließende Darstellung werden.

Da Du ja bereits größere Datenmenge in 'nem Chart anzeigen konntest, wäre es sinnvoll den Aufbau der Dateien so zu gestalten, dass Du die Daten aus den Dateien einfach in das Chart einlesen kannst.

Wie sieht denn das Array aus, welches zu schon eingelesen hast?

Eventuell kann man ja eine einfache und schnelle Schreibmethode für die Dateien entwickeln.

Zeigst Du die Daten aus dem Array so ähnlich an?

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
var
  temparray: array of double;
  i : Integer;
  k : Integer;
begin
  Setlength(temparray,10000);
  for k := 0 to Chart1.SeriesCount - 1 do begin
    for i := 0 to Length(temparray) - 1 do begin
      temparray[i] := i * k;
    end;
    Chart1.Series[k].Clear;
    Chart1.Series[k].AddArray(temparray);
  end;
end;

Dann könnte es hilfreich sein, für jeden Messwert eine eigene Datei zu erstellen.

Das Lesen könnte dann so, wie hier beschrieben dynamisches Array aus Filestream lesen, erfolgen.

[mensch72]

der Gedanke "Ringpuffer" ist ja nahe liegend, aber hier glaube ich doch nicht sinnvoll!

Warum alles immer Speicher halten und warum löschen?

Aufzeichnung:
Das ist ein typischer Fall, wo man Records(fixedSize) binär mal eben fortlaufend auf Platte schreibt. Das klappt mit Datenraten von noch nichtmal 1ms problemlos und den Plattenplatz nehme man als "endlos" für eine Woche und rollierend 5Wochen auf Platte. Also nix SQL/DBMS oder dynamische Arrays.

ListenDarstellung/Auswahl:
erstmal eine "virtuelle" Liste wo man locker hunderte Mio an Datensätzen darstellen und durch scrollen kann. Bei View wird schlicht per IndexNr mal RecordSize ein Seek auf das Datenfile gemacht und dann die zur aktuellen Anzeige x benötigten Records per Schleife linear geladen und direkt verarbeitet. Wer optimieren will macht sich tägliche IndexFiles wo schon ein paar vorberechnete Min/Max/... Werte zu ersehen sind.

ChartDarstellung:
Ein simpler Linienchart im Fastmode hat sogar die Optimierung ob alles gezeichnet werden soll, oder nur das was der Bildschirm an Pixelauflösung hergibt.
2,5Mio Points pumpe ich in rund 220ms in den Chart samt Komplettanzeige. Zoom geht/ist dann live ganz ohne Verzögerung.

Wer ein gutes "virtuelles Array" hat, also grob gesagt per FixedRecords & FileSeek ein beliebig großes auf Festplatte gespeichertes Array mit auch auch über 1Mrd Records so verwaltet, das man Record[x] im Prinzip beliebig abfragen und verwenden kann.. der tut sich bei sowas sehr leicht.
QuickAndDirty kann man das auch per Index*RecordSize als FileSeek und dann per Schleife lösen, das hat aber keinen Cache und sollte so nur linear vorwärts lesen.

Anbei mal 2 Bildchen von einer nun schon sehr alten Testsoftware aus 2009, welche mal eben ~300Mio Datensätze von Währungstransaktionen im ms Bereich eine Wochenweise Visualisierung samt virtuellem Scroll auf Tages und Record Basis ermöglicht.

=> Teechart ist zwar nicht das optimale Mittel, aber solche Datenmengen sind damit durchaus möglich.
=> Visuelle Aggregationen zur Datenreduktion sind effektiv, aber wenn Zoom bis auf Einzelpunkt oder echtes Playback gewünscht ist, muss man die DatenRecords auch unverarbeitet einzeln speichern. (im Finanzbereich/HFT sind solche Datenmengen durchaus auch üblich:) )

[Ro90]

Zitat:

Zitat von Perlsau (Beitrag 1324557)

Um mich nochmal zu vergewissern: Die 1600 Signale pro Sekunde sollen nicht im laufenden Betrieb abgenommen und gespeichert werden, sondern erst dann, wenn der Elektriker mit seiner Software an der Maschine ist, nachdem ein Fehler aufgetreten ist. Oder muß der Elektriker dann doch den Zeitraum während der Produktion, in dem der Fehler auftrat, überprüfen und analysieren können? Egal wie die Antwort ausfällt, mir ist der Zwang für die hohe Geschwindigkeit der Darstellung noch immer nicht so recht klar geworden: Wenn die Signale in Echtzeit während der Produktion dargestellt werden sollen, frage ich mich natürlich, zu welchem Zweck dies erfolgen soll. Es macht ja keinen Sinn, denn die Signale müssen ja in erster Linie für die spätere Auswertung gespeichert werden. Mit dem schnellen Wechsel der Signale kann ein Beobachter, der da ab und zu mal draufschaut, doch nicht wirklich was anfangen, oder? Eine neben der Speicherung erfolgende Anzeige würde die Speicherung mehr oder weniger verzögern oder gar die kontinuierliche Speicherung der Werte während der Produktion behindern. so daß die gespeicherten Werte nicht mehr vollständig wären.

Im laufendem Betrieb sollen die Daten in Echtzeit abgespeichert werden, auch wenn der Elektriker nicht da ist.
Der Bedienmann merkt ein Fehler an der Anlage wenn eine Fehlverhalten auftritt (z.B Holzbrett wird in falsche Etage eingelagert),
der Bedienmann hat keine Sicht auf die Software (die Steht irgendwo am Schaltschrank), jedoch merkt er einen Fehler indem die Anlage was falsches gemacht hat,
und er schreibt sich dann die Zeit auf oder er drückt eine Taste die in einer Tabelle ein Ereigniss einfügt (hat aber nichts mit der Aufzeichnungssoftware zu tun)
Der Elektriker kommt dann und muss auf die Daten zurückschauen können.
Im Prinzip müsste die Chart nichts anzeigen wenn der Elektriker nicht da ist sonder nur die Daten wegspeichern,
aber es währe schön dass es ab und zu (evtl. 10sec) eine Chart.repaint macht.
ist aber nicht das problem weil ich da ja nicht den ganzen Tag reinlade sondern nur immer 10 sekunden.

Zitat:

Zitat von Perlsau (Beitrag 1324557)

Zumindest für den Elektriker spielt die Geschwindigkeit der Darstellung dann keine Rolle mehr, denn der muß die Daten nicht in Echtzeit ablaufen sehen, um den Fehler einkreisen zu können. Er muß sich lediglich in den Daten bewegen (scrollen) können.

Nein die Geschwindigkeit der darstellung spielt dann keine Rolle mehr.#
Der Elektriker z.B um 13:00Uhr kommt, fragt den Bedienmann wann hat die Anlage ein Fehlverhalten gehabt.
Wenn der Bedienmann dann sagt um so ca. 09:00 Uhr, dann geht der Elektriker zur Software
wird dort eine Zeit eingeben von z.B. 08:50 bis 09:10 dann soll er die Signale von diesem Zeitraum im Chart sehen.
Und kann damit z.B sagen ob in diesm Zeitraum ein Sensor einen Fehler verursacht hat.

Zitat:

Zitat von nahpets (Beitrag 1324558)

Also nochmal, damit ich's (hoffentlich) verstehe.
Ein Maschine hat ein undefiniertes Problem.
Ein Elektriker schließt die Überwachungssoftware an und geht.
Der Bediener beobachtet die Anzeige und reagiert bei einem Ausreißer.

Die Daten einer Minute zeigst Du für eine Minute im Chart an. Dann hat der Bediener Zeit, jede Minute nach Ausreißern zu suchen und 'ne Taste zu betätigen oder sich die Zeit aufzuschreiben. Bei der Datenmenge "live" zuzuschauen und zu reagieren, halte ich für extrem anstrengend und dürfte recht schnell zu einer Ermüdung führen, die bei einem Maschinenbediener sicherlich nicht risikofrei ist.

Wenn jetzt per Tastendruck oder Aufschreiben der Zeitpunkt des Ausreißers bekannt ist, kann sich der Elektriker zu einem späteren Zeitpunkt die Daten aus der Datei des "Ausreißerzeitpunktes" anzeigen lassen und per scrollen jeweils eine Minute vor- oder zurückscrollen.

Ja genau, der Bedienmann sieht den Ausreißer aber durch fehlverhalten an der Anlage (z.B Brett in falscher Etage)
er schreibt dann die Zeit auf, er hat mit der Software nichts zu tun.
Nur der Elektriker der später kommt geht dann zur Software.

Zitat:

Zitat von nahpets (Beitrag 1324558)

Wie sieht denn das Array aus, welches zu schon eingelesen hast?
Eventuell kann man ja eine einfache und schnelle Schreibmethode für die Dateien entwickeln.
Zeigst Du die Daten aus dem Array so ähnlich an?

Ich löse es so wie in der angehängten pdf-Datei auf Seite 3, 4

Zitat:

Zitat von nahpets (Beitrag 1324558)

Das Lesen könnte dann so, wie hier beschrieben dynamisches Array aus Filestream lesen, erfolgen.

Danke, wird mir sehr weiter helfen.

Vielen Dank

[Sir Rufo]

Wir können ja mal einfach rechnen:

16x

Delphi-Quellcode:

real

+ 1x

Delphi-Quellcode:

TDateTime

=> 17* 8 Byte => 136 Byte

Dieses Datenvoulumen haben wir alle 10 ms

Macht 13.600 Byte pro Sekunde => 13,4 KB/s

Das sollte eine handlesübliche Festplatte locker schaffen

Und für 24h kommen wir auf ca. 1,2 GB Daten.

Auch das sollte eine handlesübliche Festplatte locker schaffen.

[Ro90]

Vielen Dank für eure Antworten!

Hat mich schon viel weiter gebracht.

Ich habe jetzt einen Lösungsansatz den ich versuchen werde.
Beim ersten Test hats schon ziemlich gut geklappt, jetzt muss ich es nur noch in die Software einbinden.

Und zwar:

für die X-Achse(DateTime) und die 16 Linien mache ich jede Minute jeweils eine Datei.
diese Dateien schreibe ich aus den einzelnen Arrays.

Das speichern erfolgt mit 2 Arrays:
gerade Minute: Array 1 wird befüllt / Array 2 wird abgespeichert und geleert.
ungerade Minute: Array 2 wird befüllt / Array 1 wird abgespeichert und geleert.
und das für jede Linie bzw für die X-Achse separat.

also 17 Arrays werden gerade befüllt, die anderen 17 gespeichert und geleert,
und das immer abwechselnd.

Das ergibt zwar nach 24h 24.480 Dateien, diese sind aber nicht all zu groß.

alte Dateien werden gelöscht, je nach Plattenfüllung.

Wenn ich dann einen bestimmten Zeitraum in meinem Chart sehen will lade ich die jeweiligen Dateien in das Chart.

Vielen Dank für Eure Hilfe

Ich werde im laufe der Woche eine kurze Rückmeldung geben obs dann geklappt hat.

[Uwe Raabe]

Zitat:

Zitat von Ro90 (Beitrag 1324548)

Jedoch wenn dieses Array 1 Mio überschreitet muss es als Ringpuffer weiterarbeiten,
also 0 löschen und alle anderen Werte nachschieben,

Ist zwar schon eine Weile her, aber ich kann mich noch erinnern, daß wir früher, wo Speicherzugriffe noch länger dauerten, einen Ringbuffer so implementiert haben, daß eben keine Daten verschoben werden mussten. Dazu wurde ein Array mit der Größe des Ringbuffers initialisiert und die Daten ganz normal über einen Indexzähler eingelesen. Erreicht der Zähler nun das Ende des Buffers wird er einfach wieder an den Anfang gesetzt und ein Merker gesetzt, der sagt, daß der Ringbuffer voll ist. Ab jetzt markiert der Zähler somit den Anfang des Ringbuffers. Daher auch der Name: man betrachtet die Daten wie einen Ring, auf dem man nur den Index verschiebt.

Will man nun die Daten des Ringbuffers lesen, unterscheidet man einen vollen und einen nicht-vollen Ringbuffer. Beim nicht-vollen wird ganz normal vom Anfang des Arrays bis zum Eintrag Zähler-1 gelesen. Beim vollen Ringbuffer liest man vom Zähler bis zum Ende des Arrays und hängt dann noch die Werte vom Anfang des Arrays bis zum Eintrag Zähler-1 dran.

Mit dieser Technik wird zwar das Auslesen des Ringbuffers etwas aufwändiger, aber das Anfügen eines neuen Wertes geht rattenschnell, da nicht jedesmal das ganze Array verschoben werden muss.

Eine einfache Implementation, die für diesen Zweck ausreichen müsste, ware in etwa sowas (nicht komplett durchgetestet!):

Delphi-Quellcode:

unit uRingBuffer;

interface

type
  TRingBuffer<T> = class
  private
    FData: TArray<T>;
    FFull: Boolean;
    FIndex: Integer;
    function CalcIndex(Value: Integer): Integer;
    function GetCount: Integer;
    function GetSize: Integer;
  public
    constructor Create(ASize: Integer);
    procedure AddValue(const AValue: T);
    function GetValue(AIndex: Integer): T;
    function GetValues(AIndex, ACount: Integer): TArray<T>;
    property Count: Integer read GetCount;
    property Size: Integer read GetSize;
  end;

implementation

constructor TRingBuffer<T>.Create(ASize: Integer);
begin
  inherited Create;
  SetLength(FData, ASize);
  FIndex := 0;
  FFull := false;
end;

procedure TRingBuffer<T>.AddValue(const AValue: T);
begin
  FData[FIndex] := AValue;
  Inc(FIndex);
  if FIndex > High(FData) then begin
    FIndex := 0;
    FFull := true;
  end;
end;

function TRingBuffer<T>.GetValue(AIndex: Integer): T;
begin
  Result := FData[CalcIndex(AIndex)];
end;

function TRingBuffer<T>.GetValues(AIndex, ACount: Integer): TArray<T>;
var
  idx: Integer;
  I: Integer;
begin
  Assert(AIndex + ACount <= Count, 'buffer has not enough elements');
  SetLength(Result, ACount);
  idx := CalcIndex(AIndex);
  for I := 0 to ACount - 1 do begin
    Result[I] := FData[idx];
    Inc(idx);
    if idx > High(FData) then begin
      idx := 0;
    end;
  end;
end;

function TRingBuffer<T>.CalcIndex(Value: Integer): Integer;
begin
  Result := Value;
  if FFull then begin
    Result := Result + FIndex;
    if Result > High(FData) then begin
      Result := Result - Size;
    end;
  end;
end;

function TRingBuffer<T>.GetCount: Integer;
begin
  if FFull then begin
    Result := Size;
  end
  else begin
    Result := FIndex;
  end;
end;

function TRingBuffer<T>.GetSize: Integer;
begin
  Result := Length(FData);
end;

end.

[Dejan Vu]

Und das ganze als Dateiringpuffer ist auch keine Hexerei: Wenn man pro Minute einen Record hat, dann schreibt man ihn unter dem Namen 'Dataxxxx', wobei 'xxxx' einfach die Anzahl der Minuten seit Mitternacht ist. Da muss man noch nicht einmal mehr Dateien löschen. Anhand des Zeitstempels zweier aufeinanderfolgenden Dateien sehe ich, wo der Ringpuffer 'anfängt'.