OSCAT Forum
network.lib => Modulentwicklung => Thema gestartet von: schwa226 am 11. April 2012, 15:20:50
-
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 (24h*60m*60s).
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!
-
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]
-
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
-
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.
-
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...
-
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!
-
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
-
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
-
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
-
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
-
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]
-
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
-
codesys network (DLOG-Testversion)
[gelöscht durch Administrator]
-
Hi
codesys network (DLOG-Testversion)
Danke
Karl
-
Erstmal Danke für die Lib - werde ich jetzt gleich mal probieren
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
-
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 ?
-
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
-
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 !
-
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
-
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:
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!
-
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
-
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)
-
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...
-
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.
-
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
-
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.
-
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
-
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
-
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