DLOG_FILE_CSV_DEMO, Zeitpunkt wann die Daten gespeichert werden

Modulentwicklung
1

Hallo!

Ich habe nun mit PC WorX 6 die Demo vom CSV Logger ausgetestet. Sie funktioniert so auch ohne Probleme jedoch habe ich noch eine Frage dazu:

Mir scheint es, dass DLOG_STORE_FILE_CSV zuerst seine Daten in der Struct oscat_DLOG_DATA zusammen sammelt.
Dies erfolgt ja mit den TRIG_T oder TRIG_M.
Die gesammelten Daten werden dann aber erst rausgeschrieben, wenn sich der Dateinahme ändert (z.B. durch #R für jede Minute)
So habe ich es zumindest beobachten können.

Nun möchte ich einen Wert einmal am Tag loggen und die 365 Werte in einer Datei pro Jahr zusammen haben.
Somit TRIG_T auf 86400 (24h60m60s).
Und im Filename ‘Meine_Daten_#A.csv’.

Nun würde das File aber erst im Jahr 2013 (Filename Änderung) zum ersten mal abgespeichert werden.
Also muss ich immer ein Jahr warten, um das letzte Jahr auswerten zu können. Es geht nicht, dass ich im Oktober den Jan-Feb des gleichen Jahres auswerte.

Gibt es eine Möglichkeit, dass man immer abspeichert wann TRIG_T/TRIG_M ausgelöst wurde?
Sozusagen Zeile für Zeile.
Oder muss man hier einen anderen Weg gehen oder den FB erweitern?

Auch ist noch das Problem, wenn in der Mitte des Jahres die SPS ausfällt sind die Daten der ersten Monate verloren da sie ja nur gepuffert waren und nciht abgespeichert.

Danke!

2

Guten Morgen!

Ich habe den DLOG_STORE_FILE_CSV nun etwas modifiziert.

Neu:
Es wird die Datei im Mode 2 geöffnet (open + write).
Neue Logdaten werden sofort in die Datei per Append eingefügt.
Bei einer Dateinamen Änderung oder bei einem Neustart der SPS wird wieder ein Header im File eingetragen.
Die alten Daten bleiben unverändert.

Diese Veränderungen sind natürlich eher nur sinnvoll wenn man lange Pausen zwischen den Logdaten hat.

TEST_55_2012.LOG:

Timestamp;Sinus;Count;Count_Bit_2;Count_Hex
2012-04-12-07:55:20;50,00;1;OFF;00000000000000000000000000000001
2012-04-12-07:55:25;52,62;5;ON;00000000000000000000000000000101
2012-04-12-07:55:30;55,23;10;OFF;00000000000000000000000000001010
2012-04-12-07:55:35;57,82;15;ON;00000000000000000000000000001111
2012-04-12-07:55:40;60,40;20;ON;00000000000000000000000000010100
2012-04-12-07:55:45;62,94;25;OFF;00000000000000000000000000011001
2012-04-12-07:55:50;65,45;30;ON;00000000000000000000000000011110
2012-04-12-07:55:55;67,92;35;OFF;00000000000000000000000000100011

TEST_56_2012.LOG:

Timestamp;Sinus;Count;Count_Bit_2;Count_Hex
2012-04-12-07:56:00;70,34;41;OFF;00000000000000000000000000101001
2012-04-12-07:56:05;72,70;45;ON;00000000000000000000000000101101
2012-04-12-07:56:10;75,00;50;OFF;00000000000000000000000000110010
2012-04-12-07:56:15;77,23;55;ON;00000000000000000000000000110111
2012-04-12-07:56:20;79,39;60;ON;00000000000000000000000000111100
2012-04-12-07:56:25;81,47;65;OFF;00000000000000000000000001000001
2012-04-12-07:56:30;83,46;70;ON;00000000000000000000000001000110
2012-04-12-07:56:35;85,36;75;OFF;00000000000000000000000001001011
2012-04-12-07:56:40;87,16;80;OFF;00000000000000000000000001010000
2012-04-12-07:56:45;88,86;85;ON;00000000000000000000000001010101
2012-04-12-07:56:50;90,45;90;OFF;00000000000000000000000001011010
2012-04-12-07:56:55;91,93;95;ON;00000000000000000000000001011111

[gelöscht durch Administrator]

3

hallo schwa226

deinen bemerkungen bezüglich der funktionsweise kann ich nichts gegenteiliges hinzufügen
das dies in deinen fall bei sehr grossen zeitabständen der schreibtrigger sehr ungünstig ist, stimmt natürlich auch

dieser umstand ist mir auch schon länger bekannt, und ich werde dies auch ändern
dies ist nur mehr eine frage der zeit (sobald als möglich)

zwischenzeitlich kannst du dir nur durch selbstgemachte anpassungen helfen

deine schnelle lösung funktioniert aber auch nur mit pcworx, da es hier in wirklichkeit gar keinen
lese,schreib oder append mode bei “file_open” gibt.

dies würde bei der network-bibliothek für beckhoff und codesys so gar nicht funktionieren

4

Danke für die Antwort.
Ich arbeite ja nur mit PC WorX, kann daher nicht beurteilen wie und ob es in anderen System so funktioniert.

Schlussendlich habe ich es so für mich umgesetzt:
Die ILC 150 ETH empfängt über RS232 alle 3 Minuten Sensordaten.
Diese Sensordaten bestehen aus Serial (OneWire), Bezeichnung, Temperatur, Spannung, Feuchtigkeit, Pressure

Wenn nun neue Sensordaten reinkommen wird dies ausgeführt:

(* log data *)
(* only if hour does match *)
IF (HOUR_OF_DT(Local_Time_UDINT) MOD Logging_Hour = 0) 
	AND (Devices[j].Last_Logging <> HOUR_OF_DT(Local_Time_UDINT)) THEN
	Devices[j].Last_Logging := HOUR_OF_DT(Local_Time_UDINT);
	DLOG_SENSOR_DATA(SensorData:=SensorData);
END_IF;

DLOG_SENSOR_DATA:

FOR j := 1 TO 8 DO
	LOG_DATA.ID_MAX := INT_TO_USINT(j);

	CASE j OF
		1 : LOG_DATA.UCB.D_STRING := LEFT(Local_Time_Date_STR, 5);
		2 : LOG_DATA.UCB.D_STRING := Local_Time_Time_STR;
		3 : LOG_DATA.UCB.D_STRING := SensorData.Serial;
		4 : LOG_DATA.UCB.D_STRING := SensorData.Name;
		5 : LOG_DATA.UCB.D_STRING := REAL_TO_STRING(SensorData.Temperature,'%3.1f');
		6 : LOG_DATA.UCB.D_STRING := REAL_TO_STRING(SensorData.VAD,'%4.2f');
		7 : LOG_DATA.UCB.D_STRING := BYTE_TO_STRING(SensorData.Humitidy,'%u');
		8 : LOG_DATA.UCB.D_STRING := WORD_TO_STRING(SensorData.Pressure,'%u');
	END_CASE;

	CASE j OF
		5,6 : REPLACE_CHARS(
				STR:=LOG_DATA.UCB.D_STRING,
				SRC:='.',
				REP:=',');
			  LOG_DATA.UCB.D_STRING:=REPLACE_CHARS.REPLACE_CHARS;
	END_CASE;

	LOG_DATA.UCB.D_HEAD := WORD#16#0101; (* Quelltype STRING, Zieltype STRING *)
	LOG_DATA.UCB.D_MODE := 1;
	UCB(DATA:=LOG_DATA.UCB); (* Daten eintragen *)
    LOG_DATA.UCB := UCB.DATA;
END_FOR;

Ergebnis:

14.04.2012;00:02:42;0000015510EC;Raum 4;22,8;10,23;0;0 14.04.2012;00:02:53;0000015606EE;Raum 5;24,0;3,86;0;968 14.04.2012;00:02:58;0000015510F6;Raum 3;22,8;1,75;31;0 14.04.2012;00:02:59;000003BB3921;Raum 1;23,1;0,00;0;0 14.04.2012;00:02:59;000003BB38A8;Raum 2;23,0;0,00;0;0 14.04.2012;00:02:59;0008025BD539;Raum 6;23,0;0,00;0;0 14.04.2012;06:02:16;0000015510EC;Raum 4;22,4;0,00;0;0 14.04.2012;06:02:32;0000015606EE;Raum 5;23,8;3,85;0;966 14.04.2012;06:02:32;0000015510F6;Raum 3;22,4;1,76;31;0 14.04.2012;06:02:33;000003BB3921;Raum 1;22,8;0,00;0;0 14.04.2012;06:02:33;000003BB38A8;Raum 2;22,6;0,00;0;0 14.04.2012;06:02:33;0008025BD539;Raum 6;22,6;0,00;0;0 14.04.2012;12:01:49;0000015510EC;Raum 4;22,5;0,01;0;0 14.04.2012;12:02:06;0000015510F6;Raum 3;22,4;1,75;31;0 14.04.2012;12:02:07;000003BB3921;Raum 1;22,8;0,00;0;0 14.04.2012;12:02:07;000003BB38A8;Raum 2;22,7;0,00;0;0 14.04.2012;12:02:07;0008025BD539;Raum 6;22,7;0,00;0;0 14.04.2012;12:02:11;0000015606EE;Raum 5;23,7;3,85;0;966

Es wird also zuerst mit Logging_Hour definiert wie oft geloggt werden soll. Momentan habe ich es so eingestellt, dass alle 6 Stunden ein Logging stattfindet.
Durch das “Devices[j].Last_Logging” wird sichergestellt, dass genau dieser Sensor nur einmal geloggt wird.
Die Daten der verschiedenen Sensoren kommen ja nicht gleichzeitig wie man dem CSV erkennen kann.
Das Speichern der CSV Datei wird auch über den Inhalt von UCB gesteuert und nicht vom DLOG_STORE_FILE_CSV.
DLOG_STORE_FILE_CSV speichert ja automatisch, wenn Daten im UCB drinnen sind.

5

hallo

ich bin inzwischen schon am überarbeiten der dlog_bausteine
(einstellbare zeit für speichern des buffer in datei und, schliessen der datei wenn nicht benötigt)

wenn du willst, kannst du ja gerne eine vorab-version haben, sobald ich etwas lauffähiges habe…
wird aber noch ein paar tage dauern

dann sollten man deine applikation mit den vorhandenen standard bausteine auch einfach lösen können

hast du noch ergänzende ideen zum thema ?
was würdest du gerne noch haben
was anderes machen etc…

6

Super! Danke!

Zeit ist nicht so wichtig, da es momentan nur hier auf dem Tisch liegt…

Wie gesagt betreibe ich es anders herum als beim Original. Der Trigger zum Speichern kommt nicht vom STORE_FILE FB sondern über den Inhalt von LOG_DATA.

Jeder Sensor hat 8 Strings die geloggt werden müssen. Somit vielleicht ein Log-Baustein mit einem Stringarray?
Derzeit habe ich bei meinem Sensor das Flag dabei ob er schon abgespeichert wurde (Devices[j].Last_Logging <> HOUR_OF_DT(Local_Time_UDINT)) . Wäre super wenn man das irgendwie über einen Log-Baustein definieren könnte.

Ich meine, wenn die nächsten Sensordaten kommen, dass der Baustein selbständig erkennt ob dieser Sensor in dieser Stunde/Minute/Sekunde (je nach Einstellung) schon geloggt wurde.

Achja, mit meinen Umbau war es mir nicht möglich einen Header im File zu erstellen. Dieser wurde dann mit jedem neuen Eintrag wieder eingetragen:

Header
Data Sensor 1
Header
Data Sensor 2
Header
…
..

Ansonsten stellt sich noch die Frage wie das dann mit dem STORE_FTP funktioniert. Derzeit nehme ich ja nur das STORE_CSV her, aber in Zukunft will ich FTP einsetzen. Es müsste also das File beim FTP selber aufgemacht und die neue Zeile angehängt werden.
Derzeit schiebt der STORE_FTP ja glaube ich einfach die ganze Datei zum FTP rüber. Habe ich aber noch nicht getestet!

7

hallo

um dein programm 100% zu verstehen, und auch dann optimal mit “standardmitteln” das gleiche umsetzen zu können
wäre es für mich viel einfacher wenn du mir den kompletten logging-part (programm) gibst

dann kann ich besser erkennen, ob deine spezielle anforderung etwas ist, was ich eventuell fix in die bibliothek integriere

8

Hallo Peewit
Dieses Problem mit dem Speicherzeitpunkt plagt mich auch. Ich möchte die Daten alle 30 min loggen, aber der File wird erst am Ende des Tages gespeichert , weil der Buffer vorher nicht voll wird.
Wenn man bei längeren Speicherintervallen nach jedem Log speichern könnte , wäre mir schon sehr geholfen.
Wie wäre es, wenn man das mit einem ( optionalen ) Parameter steuern könnte? Dieser Parameter sollte nach der Erfassung im Buffer ein sofortiges Schreiben auf den File auslösen. Da kann sich dann jeder Anwender selbst programmieren, wann das passieren soll.
Des weiteren ist ein Parameter nützlich, mit dem man zwischen "create and open " und “append” umschalten kann.
Diese Änderungen wären für Langzeitlogs schon sehr nützlich.

Du erwähntest etwas von eine " testversion " - ist die schon so weit ?

Viele Grüße JSED

9

Hallo
Ich habe schon was am laufen
In einer woche kann ich eine testversion hergeben

In der neuen version ist das speicherproblem behoben,und man kann selber definieren wann gespeichert werden soll, und die datei wird auch immer wieder automatisch geoeffnet und geschlossen

10

Hallo Peewit,

mein Problem mit der Speicherzeit beim DLOG_STORE_FILE_CSV ist immer noch ungelöst. Habe selbst ein paar Sachen probiert, aber einen Absturz produziert – irgendwie ist immer der Wurm drin.
Funktioniert die Testversion bei Dir schon ?
Danke JSED

11

ja, aber alles noch testversion !!

das projekt kannst du als oscat_network_lib 1.30 einbinden

darin sind auch im ordner “demo” die dlog_ demoprogramme zu finden

[gelöscht durch Administrator]

12

Sorry für die späte Antwort
Danke für den Link, aber ich arbeite mit Wago und Codesys - mit zwt kann ich nichts anfangen - war mein Fehler, daß ich nichts erwähnt habe .
Strukturuierter Text wäre mir das Liebste - oder eben eine Lib

Danke
jsed

13

codesys network (DLOG-Testversion)

[gelöscht durch Administrator]

14

Hi

Danke

Karl

15

Erstmal Danke für die Lib - werde ich jetzt gleich mal probieren

jsed

16

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

17

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 ?

18

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

19

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 !

20

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