RealTimeChart mit TeeChart und großer Datenmenge

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