DLOG_STORE_FILE_CSV Dateigröße der Log-Datei

[Ellie]

Hallo OSCAT Team,

im Zusammenhang mit den Logger-Bausteinen aus der network.lib habe ich mit der Funktion SysGetFileSize
versucht eine Schutzfunktion zu basteln, die verhindern soll, dass das ohnehin schon spärliche Dateisystem
einer Wago 841 mit einer zu großen Log-Datei zugemüllt wird. Jedoch musste ich feststellen, dass die o.g.
Funktion bei einer zyklischen Auswertung anscheinend das Data-Logging durcheinanderbringt und es werden nicht
mehr alle Messwerte in der Datei erfasst (es wird z.B. 0.00 geloggt anstatt der tatsächlichen Variablen).
Vielleicht wird das Filesystem von der Funktion zu stark gefordert und kommt aus dem Tritt.
Wäre es nicht viel einfacher in dem Baustein DLOG_STORE_FILE_CSV eine Variable mit laufen zu lassen, die die
Dateigröße (Anzahl der gespeicherten Bytes) automatisch mit hoch zählt, oder noch besser, eine max. Dateigröße
vorgeben, die Bausteinfreigabe 'Enable' als IN_Out deklarieren und wenn die max. Dateigröße erreicht ist,
wird Enable automatisch deaktiviert.
Geplant ist eine mobile Messwerterfassung für den Aussenbereich (ein Ablegen der Daten per FTP bei dieser Anwendung wäre zu aufwendig),
die Aufzeichnungsdauer als auch eine exakte Berechnung der Dateigröße im voraus lässt sich nicht genau durchführen,
die Messwerte können vor dem Komma ein bis dreistellig sein, so dass dann die Dateigröße entsprechend variiert.
Toll wäre auch, wenn man den Parameter X.ID_Max manuell initialisieren könnte, so dass man DLOG_Bausteine nach belieben deaktivieren und zuschalten könnte, vorausgesetzt X.ID_Max passt sich dann entsprechend an.
Die Bausteine laufen ansonsten wirklich prima, deshalb ist dieser Beitrag nicht als Kritik, sondern als 'Zuckerl' zu sehen.

Gruß Ellie

[peewit]

hallo

1. wenn ein Sysgetfilesize den datenlogger durcheinander bringt, dann würde ich es als systemfehler mal vorab einstufen
es steht auch nirgends geschrieben das man das bei einen geöffneten file nicht machen darf.


2. dateigroesse
dazu habe ich mir auch schon früher gedanken gemacht, aber kein schlüssigen , vernünftiges konzept gefunden
normalerweise hat man einen ziemlich gleichbleibenden wiederkehrenden aufnahmetakt, soasss man abschätzen kann
wann eine datei eine kritische groesse erreicht, und auf grund dieser zeit man dann einfach in eine neue datei loggt.
dass kann man mit dem dynamischen dateinamen sehr einfach und automatisiert machen
somit dachte ich mir das man das problem der dateigroesse gar nicht bzw. selten hat.

lösung ?:
ich würde auch gerne etwas für dateigroesse integrieren, aber dazu gibt es einige ungeklärte punkte
wenn die datei zu gross ist, braucht man einen neuen dateinamen
man sollte wiederkehrende dateinamen wählen, damit keine dateileichen entstehen, und sich die sps nicht mit datenmüll füllt.

als notlösung kannst du auf bausteininterne daten auch direkt zugreifen

DLOG_STORE_FILE_CSV.FSD.FILE_SIZE = aktuelle dateigroesse in bytes

wenn die dateigroesse zu gross ist, musst du nur den dateinamen ändern, mehr ist nicht notwendig !


3. variable anzahl an bausteinen
x.id_max wird bislang nur im allerersten programmzyklus einmalig bestimmt.

wenn du die datenlogger bausteine bedingt aufrufst, je nach konfiguration, so würde nach einen spannungsreset
es schon so funktionieren , da hier der x.id_max neu bestimmt wird.

es wäre auch machbar, das immer bei einer positiven flanke von DLOG_STORE_FILE.CSV.ENABLE die baustein id und id.max bestimmt werden, dazu müsste ich bei jeden satelliten-dlog-bausteine ein enable hinzufügen. so braucht man nur den logger sperren, die
die jeweiligen satellitenbausteine "enable/disable" machen und wieder den logger freigeben

ich muss halt immer schauen das wir funktionien integrieren, die für die breite masse interessant sind, und andere user nicht unnötig verwirren, und alles verkomplizieren.


danke für die anregungen

[Ellie]

Danke für die schnelle Antwort und Hilfe

habe das Grundprinzip mit Dateinamen ändern und überschreiben etc. verstanden und auch schon erfolgreich ausprobiert.
Mein Grundgedanke zu 2.) war der, dass sich der Logger bei Erreichen einer kritischen Dateigröße einfach von selber abschaltet, wenn der Speicher droht voll zu werden, da es sich in diesem konkreten Fall um eine mobile Messstation für den Aussenbereich handelt, kein FTP Server, kein Email oder sonst. vorhanden.
Station wird ausgesetzt, Daten werden aufgezeichnet, Speicher voll, Logger schaltet ab, Station einsammeln und fertig.

Werde natürlich gleich die interne Notlösung mit 'DLOG_STORE_FILE_CSV.FSD.FILE_SIZE = aktuelle dateigroesse in bytes' testen.

Warum das mit Sysgetfilesize nicht richtig funktioniert konnte ich in der Kürze nicht herausfinden, vieleicht werden auch andere Prozesse von dieser Funktion ausgebremst und die Variablenübergabe klappt nicht mehr richtig, bei den onlinewerten aus den Messbausteinen gab es zumindest keine Aussetzer.

Die Idee mit der variablen Anzahl an Bausteinen finde ich klasse, ich habe das Szenario mit dem "enable/disable" an den jeweiligen Satellitenbausteinen mit der Funktion "EN/ENo" in CFC (Menü Rechtsklick) schon im Vorfeld ausprobiert, bin aber natürlich wie Du schon beschrieben hast an dem x.id_max Problem gescheitert.
Wenn der Baustein DLOG_STORE_FILE_CSV bei jedem Enable die id und die id.max ermittlen würde, müsste es klappen und wäre ausreichend, die Freigabe der anderen Bausteine lässt sich wie schon erwähnt in CFC selber hinstricken.

Nochmal Danke für die schnelle Hilfe

Gruß Ellie

[Ellie]

Hallo Peewit,

der Tipp mit dem direkten Zugriff auf die interne Variable DLOG_STORE_FILE_CSV.FSD.FILE_SIZE war goldrichtig und ist absolut keine Notlösung. Überwachung der Dateigröße mit einem nachgeschalteten "GT"-Baustein und anschließendem R (Reset) der Enable-Variablen am DLOG_STORE_FILE_CSV Baustein lässt den Logger zuverlässig beim Überschreiten des Wertes am GT-Baustein anhalten. Die Variable der Dateigröße erhöht sich jedes mal, wenn ein voller 4kB Block in die Datei geschrieben wird. Prima und Danke nochmal.


Ein kleiner Tipp für alle DLOG-Fans:

Möchte man, dass das Datum und die Uhrzeit des Zeitstempel-Bausteins auch in getrennten Spalten erscheinen einfach folgendes eingeben:
Beim Eingang FMT: z.B. '#H.#D.#A , #N:#R:#T'
Beim Eingang Column: 'Datum , Uhrzeit'     wenn der Seperator wie in diesem Fall ein Komma ist.

[peewit]

hallo

DLOG_STORE_FILE_CSV.FSD.FILE_SIZE

schön das es funktioniert, aber es ist aber auch eine konzeptlücke in codesys
den eigentlich sollte für die bausteine eine kapselung existieren, sodass man im anwenderprogramm auf intern deklarierte variablen
von aussen eigentlich gar nicht zugreifen können sollte
(das erinnert mich an SIMATIC -> jeder darf alles , nichts wird verhindert, geprüft -> wird schon gut gehen)

es ist oft praktisch, ist aber eine lösung die nicht auf allen systemen funktioniert, da es eigentlich nicht funktionieren sollte.

aber gut, für dich ist es eine brauchbare lösung ..
---------------

ich werde demnächst auch eine option beim dlog_store_file_csv einbauen, damit man besser steuern kann, wann die daten in die datei geschrieben werden, und man nicht immer auf einen vollen buffer warten muss. das ist auch ein gewissen risiko bei spannungsausfall dass hier oft viel verloren gehen kann.

--------------
getrennte spalten für Datum und uhrzeit
deine lösung geht, man muss halt auf das richtige trennzeichen achten

man kann aber auch einfach zwei DLOG_DT benutzen

1. DLOG_DT mit '#H.#D.#A'
2. DLOG_DT mit '#N:#R:#T'

da sind wir hier sehr flexibel.