Hallo,
ich habe folgendes Problem mit dem DLOG_STORE_FILE_CSV-Baustein:
Ich verwende den Baustein auf mehreren Beckhoff CX (basic 333 und network 130) - diese habe ich mit dem Baustein ausgiebig getestet, was auch einwandfrei funktioniert hat. Nach der Inbetriebnahme ist mir nun aufgefallen, dass es anfangs funktioniert aber irgendwann ist das LOG-Ergebnis unbrauchbar, weil die Zeilenumbrüche falsch gesetzt werden…
Hier ein Beispiel wie das Log-File dann aussieht:
Datum/Zeit;Durchfluss.Messwert;DFL_Zaehler.Zaehlerstand_Tag;2015-07-07 08:27:27;6.9;180;2015-07-07 08:27:46;5.2;;2015-07-07 08:29:31;;181;2015-07-07 08:32:22;;182;[b]Statt den Zeilenumbrüchen wird fälschlicherweise ein Separator gesetzt![/b]
So sollte es eigentlich aussehen:
Datum/Zeit;Durchfluss.Messwert;DFL_Zaehler.Zaehlerstand_Tag 2015-07-07 08:27:27;6.9;180 2015-07-07 08:27:46;5.2; 2015-07-07 08:29:31;;181 2015-07-07 08:32:22;;182
Beim Testen konnte ich das Fehlverhalteneinfach vorerst noch nicht reproduzieren…
Ich habe den DLOG_REAL FB so abgeändert, dass nur bei einer wirklichen Delta-Änderung ein Wert geschrieben wird - wenn der Trigger von extern kommt, wird ‘’ geschrieben (deshalb auch die Leereinträge in dem Log oben).
Die Ursache für die fälschliche Separator-Setzung habe ich in folgendem CODE-Teil gefunden:
n := n + USINT#1;
IF n = X.ID_MAX THEN (* letztes Element einer Zeile *)
n := USINT#0;
PT.BUFFER[idx] := BYTE#16#0D;
idx := idx + 1;
PT.BUFFER[idx] := BYTE#16#0A;
ELSE
PT.BUFFER[idx] := SEP;
END_IF;
Ich habe gesehen, dass im laufenden Programm die Variable n eine großen Wert hatte > X.ID_MAX. Da die Rücksetzbedingung für n allerdings eine ISTGLEICH-Operation ist, wird der Wert nie mehr zurückgesetzt, wenn er einmal größer als X.ID_MAX ist.(dieser lag momentan richtigerweise beim Wert 3)
Damit das passieren kann, müsste X.ID_MAX kurzzeitig den Wert 0 oder einen größeren als den tatsächlichen Wert angenommen haben. Nachdem ich n manuell wieder auf 0 gesetzt habe, funktionierte das Logging auch wieder richtig.
Der DLOG_STORE_FILE_CSV-Baustein wird in meinem Programm nur in einem bestimmten Fehlerfall aktiviert (danach wird das ENABLE wieder auf false gesetzt) - ENABLE kann also zwischen true und false wechseln.
X.ID_MAX wird ja in der step_1 CASE-Anweisung wieder auf 0 gesetzt, wenn ENABLE von false auf true wechselt. Der Schreibvorgang unter der step_2-Anweisung könnte da aber noch laufen und dann hätte man den Fall, dass n weiterzählt und beim nächsten ENABLE dann größer als X.ID_MAX ist… Eventuell ist das die Ursache…
Ich habe vorerst mal eine zusätzliche Rücksetzung unter 00 von step_1 hinzugefügt und die ISTGLEICH gegen eine GRÖßerGLEICH-Operation ausgetauscht - ich hoffe dass das die einzige Stelle ist, an dem Variablen nicht richtig zurückgesetzt wurden…