RealTimeChart mit TeeChart und großer Datenmenge

[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 von Ro90:

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

[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 von Ro90:

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 von Ro90:

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 von Ro90:

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 von Ro90:

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 von Ro90:

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 )

[Uwe Raabe]

Zitat von Ro90:

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.