DLOG_FILE_CSV_DEMO, Zeitpunkt wann die Daten gespeichert werden

[jsed]

Hallo Peewit,

also ich habe die neue Version von DLOG_STORE_FILE_CSV jetzt schon mal ausprobiert -  bis jetzt keine Probleme !
Alles funktioniert einwandfrei !
Ein kleinse Problem habe noch :
Warum habe ich jetzt plötzlich 10000 byte im retain specher verbraucht , das ist irgendwie etwas viel für den Filenamen in DLOG_Store_File_CSV?

Ich finde , man sollte diesen "Faden" aus dem Bereich PC WorX in das allgemeine Forum zur Network Lib verschieben.

Viele Grüße
jsed

[peewit]

hallo

das mit den retain speicher problem kann ich noch nicht nachvollziehen

die jeweiligen DLOG_STORE_* bausteine benötigen je ca. 100 bytes retain speicher.


kann es sein das du hier etwas selber verbrauchst ?

[jsed]

Ich bin noch auf der Suche
wirklich die einzige Retain variable scheint der Filename zu sein - trotzdem fehlen mir ca.10000 von den verfügbaren ca. 16000

HEUREKA

Während des Schreibens ist es mir siedend heiß gekommen: Codesys speichert speicher die gesamte Instanz eines FB im Retain , wenn auch nur eine einzige Variable innerhalb des Blocks RETAIN ist .
Lösung :
für jede Instanz eines  DLOG_Store_file_CSV Bausteines wird im Program ( nicht in einem FB) eine Retain Variable mit dem Filename definiert.
Im DLOG Store_file:CSV wird diese Variable als Var_IN_OUT definiert.

Ergebnis 81 Byte im Retain

[peewit]

hallo

tja das ist ja eine ziemlich grosse macke bei codesys
da wird mir nichts anderes übrig bleiben als die remanten var aus den fb zu nehmen und als in/out zunutzen

danke für den tip !

[jsed]

Hallo Peewit und andere in diesem thread

Die neue Version DLOG_Store_File_CSV läuft jetzt seit Wochen absolut fehlerfrei auf einer Wago 841er.
Einzige Änderung:
   wie oben beschrieben die Retain Variablen aud dem FB herausgeholt und als global retain definieren.
Jetzt kommt nur die Überwachung des Speicheplatzes dran.

Ansonsten ist mein Problem wirklich super gelöst !
jsed

[schwa226]

Als Starter dieses Themas will ich mich auch nochmal dazu melden!

Danke für den neuen CSV Log! Werde ich noch austesten!

Aber ich habe noch eine andere Frage zu dem Log Thema:
Und zwar hatte ich es bis jetzt, dass ich die Dateien Lokal auf der SPS hatte.
Da reichte ja der DLOG_STORE_FILE_CSV FB aus.
Hier werden dann ja auch im Append Mode die neuen Log Daten am Ende der Datei eingefügt.

Nun möchte ich die Log Dateien aber auf einen FTP Auslagern. Dazu gibt es ja das DLOG_FILE_TO_FTP.
Aber soweit ich das Verstehe schiebt dieser FB die Datei neu zum FTP.
Eigentlich ist es hier notwendig die Datei vom FTP zu öffnen und dann die neuen Daten anzuhängen.

Braucht man dann eine andere Version von FILE_SERVER in der DLOG_STORE_FILE_CSV um die Datei nicht Lokal sondern vom FTP zu öffnen!?

EDIT:
Ich glaube der bessere Weg wird sein, die Log Zeile einfach per TELNET_PRINT an einen extra Server zu schicken.
Dieser kann dann die empfangenen Strings in die richtige Datei schieben und/oder auswerten.

Nochmal EDIT:
Weiteres herumlesen hat mich auf REST und SIZE aufmerksam gemacht. Wenn der FTP Server das Unterstützt könnte man ein Append machen! Also zuerst per SIZE die Filesize des Remotefiles bestimmen. Danach mit REST die Postion für den Upload weitergeben. Danach per STOR die Daten an den FTP Server. Dieser sollte dann an der angebenen Position die neuen Daten anhängen.
Das könnte doch mit einer Erweiterung des FTP_CLIENT FB funktionieren, oder?

So könnte die Abänderung für ein Append aussehen:

Code Auswählen Erweitern

54: IF rcv_state = 200 THEN (* 200 = Command okay *)
IF FTP_DOWNLOAD OR FTP_APPEND THEN (* Datei von FTP Empfangen oder FTP Append *)
snd_text := CONCAT('SIZE ', ftp_path); (* SIZE /PFAD/FILENAME *)
next_step := 56;
ELSE
step := 60;
END_IF;
END_IF;

56: IF rcv_state = 213 THEN (* 213 Filesize *)
ELEMENT_GET(SEP:=BYTE#32,POS:=1,ELEMENT:=rcv_text);
rcv_text := ELEMENT_GET.ELEMENT;
str1 := ELEMENT_GET.ELEMENT_GET;
ftp_file_size := STRING_TO_UDINT(str1); (* Dateigroesse in bytes gestimmen *)

IF FTP_APPEND THEN (* Set append postion to end of remote file *)
snd_text := 'REST ';
snd_text := CONCAT(snd_text, str1); (* REST FILESIZE *)
step := 57;
ELSE
step := 60;
END_IF;
END_IF;

57: IF rcv_state = 110 THEN (* 110 Restart Marker *)
step := 60;
END_IF;

Wenn der Server das REST unterstützt muss man aber aufpassen! Das greift auch beim Download (Resume Download) und die Postion muss bei jedem neuen Upload/Download neu gesetzt werden!

[peewit]

hallo

es gibt im ordner "demo" in der bibliothek auch beispielprogramme mit dlog (auch für dlog ftp) -> schau dir das an
es wird einfach zum normalen dlog_store_file_csv ein zusätzlichen ftp baustein benutzt
mehr ist es nicht


was gefällt dir denn daran nicht, das zuerst eine datei erzeugt wird und dann auf einen ftp geschoben wird
das hat den vorteil das die datenaufzeichnung sicher funktioniert, und eine nicht funktionierende ftp verbindung auch über lange zeit kein problem macht.

wenn wir online auf ftp file schreiben, hast du ein problem wenn das netzwerk bzw. der ftp server nicht funktioniert !

wenn du die werte sofort online verfügbar haben möchtest , dann wäre es die professionellste variante es mit dlog_mysql zu machen

[schwa226]

Danke für die Info!

Bei FTP stellt sich mir das gleiche Problem wie beim Lokalen Speichern.
Ich habe ein LogFile, dass alle paar Minuten einen neuen Eintrag erhält.
Also Zeile für Zeile.

Beim derzeitigen FTP Log wird immer die Datei neu rübergeschoben und die alten Daten werden überschrieben.
Es wäre eine Möglichkeit das Logfile zuerst vom FTP auf die SPS zu holen und dann zu bearbeiten.
Diese bearbeitete Datei dann wieder auf den FTP. Hier stößt man dann aber auf ein Problem wenn die Log Datei zu groß wird.

Gestern habe ich es dann aber noch so umgebaut, dass es mit dem REST funktioniert. Ich logge nun direkt in den UNI_CIRCULAR_BUFFER. Ein neuer DLOG_TO_NETWORKBUFFER schreibt die Daten in einen Network_Buffer. Diesen schicke ich dann per Append/Resume an den FTP. Also sozusagen ein DLOG_TO_FTP.
War eine kleine Spielerei denn:
Beim Command SIZE wenn kein File Vorhanden ist kommt 550 zurück.
Beim Command REST kommt 350 zurück wenn der Server es aktzeptiert.

Die meisten Probleme waren aber von der Serverseite mit Proftpd.
Da musste ich erst etwas herumspielen bis mich dieser zuließ ein Append/Resume durchzuführen:
550 Permission denied (wenn File schon vorhanden) (Fehler in FTP Schreibrechte)
451 Append/Restart not permitted, try again (Fehler in FTP Resume Settings)

[peewit]

Hallo

zu ganz habe ich dein problem noch nicht verstanden

beispiel:

alle 15 minuten wird ein datensatz geloggt.
es wird für jeden tag eine neue datei erzeugt.
somit hast du am laufenden tag die daten auf der sps in der datei
sobald ein neuer tag beginnt wird die datei vom letzten tag auf dem ftp geschoben
und die datei für den aktuellen tag wird wieder lokal erzeugt.
auf den ftp hast du dann von jeden tag eine eigene datei !

die alten daten werden am ftp nur dann überschrieben, wenn du denn dateinamen immer gleich lässt

damit jeden tag in eine neue datei geloggt wird, ist mit einem dynamischen dateinamen automatisch lösbar...

zum hinzufügen an eine bestehende ftp-datei sollte doch eingentlich ein einfacher APPEND befehl reichen...

[schwa226]

Das Problem das ich habe ist, dass ich keine Tägliche Datei erzeuge sondern eine Jährliche. Und davon auch einige da für jeden Sensor ein eigenes File gemacht wird.

Deswegen habe ich Angst, dass da einmal der Speicher der SPS knapp wird... Auf dem ftp der im Netzwerk am Router läuft habe ich 2GB. Bei der ILC 150 weis ich nicht einmal wie gross der ftp Speicher ist. Ich habe nur Daten zum Programmspeicher und ähnlichem gefunden.

Es sollte ja auch als Info dienen, dass es mit dem FTP_CLIENT möglich ist für Down und Upload ein Resume/Append durchzuführen.

[peewit]

hallo

die frage ist ob es unbedingt eine jährliche datei sein muss
wöchentlich oder monatlich wären ja auch keine katastrophe

aber gut, bei dem wunsch ist die direkte ftp variante mitunter sinnvoll
ich werde es mir überlegen , ob ich langfristig auch diese variante mit auf nehme....

wenn du lust hast kannst du mir ja deinen code schicken.... und wenns passt werde ich daraus was offizielles stricken
(wird aber dauern... weiss jetzt schon nicht was ich zuerst machen soll ..)


die ilc 1xx haben so glaube ich 3 mb flashspeicher für alle daten (SPS Bootprogramm + WEB Visudaten + Anwenderdaten
es gibt aber inzwischen die ilc 1x1 die haben alle einen sd-karten slot, wo du dann auch eine 2gb sdkarte reinschieben kannst

[GES123]

Hallo dlog-Meister peewit,
zuerst mal vielen Dank für die Datenlogger-Bausteine und die Testversion des neuen dlog_store_file_csv.
Auch ich verwende den Baustein um Langzeit-Logging zu betreiben (Eaton XV102, Codesys V2.3.9).  Das Schließen der .csv-Datei alle 15sek hat mein Problem gelöst. Auch sonst läuft der Baustein seit 1 Woche stabil.
Für eine neue Version hätte ich noch einen Vorschlag:
Und zwar gibt es auch immer Daten, die nicht dauernd mitgelogt werden müssen, weil sie statisch sind. Diese sind aber bei der Fehlersuche extrem nützlich. (In meinem Fall: Name des Projekts, Standortkoordinaten, Software-Version, ....).
Um die CSV-Datei nicht zu groß werden zu lassen, wäre es doch sinnvoll, diese Daten in einen Überschriftsbereich der csv-Datei einmal (und nur einmal) zu schreiben. Ab z.B. Zeile 5 folgen dann wie gehabt die Prozessdaten.
Bis dahin werd ich eine zweite Log-Datei erstellen, die nur einmal täglich diese statsichen Werte aufzeichnet und speichert.
Vielen Dank nochmal.

[peewit]

hallo

ansich ist die idee ja nicht schlecht, sie passt aber leider nicht ganz ins konzept der erstellten datentabellen
da diese informationen nicht ins layout, schema der daten passen
aber du könntest dir mit einem kleinem trick selber helfen

angenommen du sammelst daten und hast in summe 5 spalten
dann kannst du beim ersten element folgende spaltenüberschrift vorgeben

column = "Projekt x;Standort y;Software z;;$0d$0aMeine Ueberschrift";

Das erzeugt eine zusätzliche zeile an oberster stelle

[GES123]

Hallo
Vielen Dank für den schnellen Tipp. Ich hab das ganze probiert und es auch zum Laufen gebracht. Es waren aber ein Paar kleine Änderungen notwendig:
-   Codesys verwendet die einfachen Anführungszeichen, nicht die doppelten.
-    Im Beispiel von peewit war ein „ ; “ zu viel.
-   Die DLOG-Bausteine (Bool, Real, String , …) lassen beim Parameter „COLUMN“ max 40 Zeichen zu. (Siehe Doku „89-oscat-network-docu-german.pdf“).

Meine Syntax im Baustein DLOG_DT:
COLUMN:= „Projekt abc;Standort xyz;$0D$0Ameine Ueberschrift‘
führt  zu folgendem Eintrag in der .csv-Datei:

Projekt abc;      Standort xyz;
meine Uebers;      

Der Rest wurde abgeschnitten.

Noch zwei Anmerkung: 
Bei den Zeichen zum Zeilenwechsel ($0D$0A) ist eine „Null“ gemeint, nicht der sehr ähnlich aussehende Buchstabe „O“.
Unter folgendem Link stehen weitere ASCII-Codes zur Zeilenumschaltung: http://www.netzmafia.de/skripten/programmieren/thomas-c/grundlagen.html

@peewit:
Eigentlich ist es doch kein Widerspruch, in eine Daten-Datei eine Überschrift einzufügen. Auch jetzt wird ja die oberste Zeile für die Spaltenüberschrift genutzt.
Vielleicht könnte man den Baustein DLOG_STORE_FILE_CSV so erweitern, dass es einen INT-Eingang gibt, mit dem man die Anzahl der Zeilen für die Überschrift definiert. Wird hier „0“ (Null) eingetragen, dann gibt es keine Überschrift und die Daten-Struktur wird wie gehabt beibehalten.
Dazu bräuchte man noch einen Eingang oder Eingänge für die Prozessvariablen (VALUE).

Vielen Dank

[peewit]

ich werde mal deinen wunsch auf die ideenliste setzen, aber das wird nicht so einfach
da wir ja auch einen xml und html dlogger haben, und wenn sollten alle die gleichen funktionen haben , und das ist wiederum noch mehr arbeit

du kannst inzwischen ja mit dem kleinen trick weitermachen, notfalls änderst du bei den datalogger bausteinen bei "column" den eingangsparameter von STRING(40) auf STRING(80) , das sollte kein problem machen