[Konzeptfrage] Messwerte speichern?

[TBx]

Zitat:

Zitat von Chemiker

aber ich habe bedenken das ich für die graphische Darstellung nach her zu wenig Zeit habe.

Ich denke, da dürfte es keine Probleme geben.
Wir haben da seit geraumer Zeit eine Kühlhausüberwachung laufen, die mehrfach pro Sekunde die Daten aller Kühlhäuser speichert.
Schluckt in dem Fall der Firebird so weg.
Ein weiterer Vorteil ist, dass Du die Auswertung zeitgleich auf beliebig vielen Rechnern visualisieren kannst, solange diese Zugriff auf die DB haben.

[tr909]

zur Speicerhung von Messwerten fällt mir spontan „Round-Robin-Database“ ein.
Dort fallen natürlich dann die Einzelwerte nach einiger Zeit weg, jedoch sind Summen, Mittwerte, etc. verfügbar. (evtl. Wäre das ja ein Alternative)

Gruß
tr909

[haentschman]

Hallo Chemiker...

Zitat:

es werden alle 30sek. alle 280 Messwerte übermittelt. Diese müssen dann noch aufbereitet werden und mit einem Zeitstempel versehen werden.

Ich glaube da besteht kein Geschwindigkeitsproblem. Da dauert wahrscheinlich die Übertragung länger als das Schreiben in die Datenbank.

Zitat:

Ich würde nicht zuerst darstellen, sondern zuerst speichern und die Daten der DB darstellen.

...dem stimme ich vorbehaltlos zu.

Wenn die Visualisierung parallel läuft könntest du das Speichern der Werte in einen Thread auslagern und dein Chart im Formular aktualisiert sich in gewissen Zeitabständen aus der DB.

:hi:

[Chemiker]

Hallo,

erst mal Danke an alle, für die tolle Ideen.

Werde mal versuchen das mit Firebird und FIBPlus umzusetzen.

Bis bald Chemiker

[mjustin]

Zitat:

Zitat von Chemiker

Hallo,

erst mal Danke an alle, für die tolle Ideen.

Werde mal versuchen das mit Firebird und FIBPlus umzusetzen.

Bis bald Chemiker

Dieser Anwendungsbereich kann auch mit einer Message Oriented Middleware gut abgedeckt werden. Firebird kann man dabei als Persistenz-Backend einsetzen. Der Vorteil ist, dass sich an einem Message Broker beliebig viele Sender (Messwerterfassungs-Clients) und Empfänger (Visualisierungs- und Verarbeitungsanwendungen) dynamisch an- und abmelden können. Auch Load Balancing ist damit sehr leicht herstellbar, da man eine Queue für die Weiterverarbeitung von mehreren PCs aus abarbeiten kann, wobei der Message Broker dafür sorgt, dass jede Nachricht nur an einen einzigen Client gesendet wird.

Auch ist die Datenbank dann nicht mehr ein Single Point of Failure - man kann sie zu Sicherungszwecken herunterfahren, während der Message Broker weiter die Daten annimmt (oder auch mehrere Broker mit automatischem "failover").

Nachrichten, die man nicht dauerhaft speichern will, kann man dabei als 'nicht-persistent' kennzeichnen, und gängige Message Broker unterstützen auch Transaktionen (z.B. Apache ActiveMQ). Clients Libraries gibt es - je nach Broker - für fast alle Plattformen und Sprachen.

Ist vielleicht zu spät für das aktuelle Projekt, aber später eventuell mal interessant.

Schönes & erfolgreiches neues Jahr

[WInfo]

Moin, Moin, Chemiker,

kannst Du bitte mal einen Beispieldatensatz bringen, wie das aussehen wird, was Dir die Messstationen zurückbringen. Ausserdem wären ein paar Erläuterungen sinnvoll, über das was Du mit diesen Daten machen würdest, welche Auswertungen, ob Auswertungen überhaupt, maschinelle Weiterleitung etc.

Denn die Weiterverarbeitung deiner Daten bestimmen das zugrunde liegende Modell.

[Chemiker]

Hallo WInfo,

der Datensatz der von der SPS kommt sieht wie folgt aus:

3 Zeichen Maschinen-ID
2 Zeichen Messstelle-ID der Maschinen
Double-Wert = MW

Mit diesen Werten werden zum Beispiel Temperatur – Kurven im TChart dargestellt. Füllstandsanzeigen von Tanks angezeigt und aufgezeichnet, Stromverbrauch von Maschinen aufgezeichnet usw.
Es ist also eine reine MW-Aufzeichnung keine Steuerung.

Im Kleinen Maßstab läuft das Programm das Problem ist jetzt nur die Masse an Daten, die jetzt anfallen.

Bis bald Chemiker

[WInfo]

Moin Moin Chemiker,

danke für deine Ausführungen, wollte zuerst schreiben, ob Du deine Auswertungen nur eine Maschine benötigst, um ggf. die Daten maschinenbezogen abzuspeichern, aber da dürfte es wohl Probleme mit den Filehandels geben, daher wird man nicht dran vorbeikommen die Daten in ein File zu schreiben. Wie möchtest Du denn gerne die Historie auswerten, nur rückwirkend auf 30 Tage oder permanent beginnend von Adam und Eva.

Denke, hier sollte man zweigeteilt vorgehen, eine Datei mit den Daten für Auswertungen und ggf. noch eine für die Historie, auf welche nur selten schreibend zugegriffen wird. Da die Daten alle lesend sind, kann man auf ein Transaction Processing verzichten, es wird bei einem Flatfile jedoh schwierig die Daten herauszuholen, aber bei der Dateigrösse (3 + 3 + 4 + 4)* 2880 * 280 = 10,8 MB je Jahr tendiere ich zu einer strukturieren Datei. Da die paar MB sehr schnell gelesen werden können und die Datensätze schnell hinzugefügt werden können, ohne weitere Indexe mit fortzuschreiben. Einen Datenbank sehe ich für diesen Einsatzbereich aktuell nicht, wäre oversized und würde zu viel Performance schlucken.

Edit: Hier noch die Datendefinition, wie ich sie verstand in der Luxusausführung mit 23 Byte Recordlänge.

Delphi-Quellcode:

TYPE
  STR3 = string[3];
  STR2 = string[2];

  TMachineInfo = PACKED RECORD
    MachineID:    STR3;
    ControlPoint: STR2;
    TimeStamp:    tDateTime;
    Measurement:  double;
  END;
VAR
  MachineInfoFile: FILE OF TMachineInfo;

Schöne Grüße