1
Beiträge anzeigen
Diese Sektion erlaubt es ihnen alle Beiträge dieses Mitglieds zu sehen. Beachten sie, dass sie nur solche Beiträge sehen können, zu denen sie auch Zugriffsrechte haben.
Seiten: [1] 2
2
oscat.lib fuer PC WorX/MULTIPROG / BLIND_SHADE_S IO Misstake
« am: 05. Oktober 2012, 19:04:01 »
Hi!
I just want to inform you that the BLIND_SHADE_S have a VAR IN/OUT failure:
Should be:
Isn't it?
EDIT:
OK, there are some more failure in this function block.
I attached a version what is compiling - but I didn't test it 100%
[gelöscht durch Administrator]
I just want to inform you that the BLIND_SHADE_S have a VAR IN/OUT failure:
Zitat
QU BOOL VAR_INPUT 0 0 0 0 0 0
QD BOOL VAR_INPUT 0 0 0 0 0 0
STATUS BYTE VAR_INPUT 0 0 0 0 0 0
PO BYTE VAR_INPUT 0 0 0 0 0 0
Should be:
Zitat
QU BOOL VAR_OUTPUT 0 0 0 0 0 0
QD BOOL VAR_OUTPUT 0 0 0 0 0 0
STATUS BYTE VAR_OUTPUT 0 0 0 0 0 0
PO BYTE VAR_OUTPUT 0 0 0 0 0 0
Isn't it?
EDIT:
OK, there are some more failure in this function block.
I attached a version what is compiling - but I didn't test it 100%
[gelöscht durch Administrator]
3
PC WorX / Re: SMTP mit GMail
« am: 24. September 2012, 14:25:34 »
Super! Danke!
Funktioniert nun ohne Probleme!
Funktioniert nun ohne Probleme!
4
PC WorX / Re: SMTP mit GMail
« am: 22. September 2012, 19:00:27 »
Nach dem Urlaub bin ich mal dazu gekommen das zu testen:
Habe es abgeändert und im Debug sehe ich den String auch richtig.
Yahoo mag das aber trotzdem nicht! -> Error 501 (Syntax error in parameters or arguments)
Wie gesagt, os eine Beschreibung das die ID "Station_01" so in das MAIL FROM reingehört habe ich nirgends gefunden.
Yahoo mag es auf jeden Fall nicht sondern nur in dieser Form:
Zitat
MAIL FROM: "Station_01" <oscat@gmx.net>' <---- funktioniert bei manchen providern nicht
MAIL FROM: "Station_01"<oscat@gmx.net>' <---- dort funktioniert es aber so (ohne leerzeichen)
Habe es abgeändert und im Debug sehe ich den String auch richtig.
Yahoo mag das aber trotzdem nicht! -> Error 501 (Syntax error in parameters or arguments)
Wie gesagt, os eine Beschreibung das die ID "Station_01" so in das MAIL FROM reingehört habe ich nirgends gefunden.
Yahoo mag es auf jeden Fall nicht sondern nur in dieser Form:
Zitat
MAIL FROM: <oscat@gmx.net>
...
...
From: "Station_01" <oscat@gmx.net>
5
PC WorX / Re: SMTP mit GMail
« am: 13. September 2012, 16:34:19 »Zitat
das was du meinst ist das man einen alias namen übergeben kann, der dann vom email client anstatt der realen email adresse angezeigt wird, das ist aber rein optisch !
Ja, ich weis das es nur Optisch ist - aber trotzdem ganz nett.
Ich habe es gerade mit Yahoo Mail ausprobiert:
Im String "MAIL FROM: <xxxx>" darf nur die email drinnen stehen.
Der oscat SMTP Client schreibt aber auch den "optisch" schönen Namen mit rein.
Das passt soweit ich das rausgefunden habe aber nicht!
Yahoo z.B. bag das nicht und bricht mit Error 501 ab.
Im String "From: "yyyy" <xxxx>" kann man den "optischen" Namen reinschreiben.
Dieser wird dann auch bei der email als Absender angezeigt.
6
PC WorX / Re: SMTP mit GMail
« am: 11. September 2012, 06:41:21 »
Danke für die Info!
Geht bei GMX das mit dem Namen (Alias) statt der email Adresse?
Ich habe einiges in Google durchsucht, aber die Methode die oscat anwendet:
MAIL FROM: "ALIAS" <mymail@provider.com>
Habe ich nirgends gefunden. Nur Infos, dass im MAIL FROM nur die Absender email mit Domain drinnen sein darf!?
In dem DATA Teil habe ich es schon gefunden:
From: "ALIAS" <mymail@provider.com>
Kann es sein das dass Alias eigentlich nicht in das Mail From reingehört?
Geht bei GMX das mit dem Namen (Alias) statt der email Adresse?
Ich habe einiges in Google durchsucht, aber die Methode die oscat anwendet:
MAIL FROM: "ALIAS" <mymail@provider.com>
Habe ich nirgends gefunden. Nur Infos, dass im MAIL FROM nur die Absender email mit Domain drinnen sein darf!?
In dem DATA Teil habe ich es schon gefunden:
From: "ALIAS" <mymail@provider.com>
Kann es sein das dass Alias eigentlich nicht in das Mail From reingehört?
7
PC WorX / SMTP mit GMail
« am: 10. September 2012, 20:06:28 »
Hallo!
Ich möchte Nachfragen, ob GMail als SMTP Server mit Oscat funktioniert!?
Mit oscat schaffe ich es nicht eine email zu verschicken:
Error_c: 076C0212
Error_t: 05
Online mit diesem Tool geht es:
http://smtper.sweetylife.com/
GMail braucht aber die Option "Require Secured Connection". Liegt es vielleicht daran?
Am Router kann es nicht liegen, da ich es mit einer Client Software im gleichem Netzwerk auch schaffe eine email zu verschicken. Ich muss aber "STARTTLS" als Connection einstellen.
Hat jemand einen Tipp welcher kostenloser SMTP Server brauchbar ist!?
Edit:
Habe es gerade noch mit Yahoo Mail versucht. Da geht das Versenden von emails. Jedoch kann man beim MailFrom keinen Alias dazu geben.
Der Server meldet Error 501 zurück.
Gibt es da noch eine Möglichkeit?
Ich möchte Nachfragen, ob GMail als SMTP Server mit Oscat funktioniert!?
Mit oscat schaffe ich es nicht eine email zu verschicken:
Error_c: 076C0212
Error_t: 05
Online mit diesem Tool geht es:
http://smtper.sweetylife.com/
GMail braucht aber die Option "Require Secured Connection". Liegt es vielleicht daran?
Am Router kann es nicht liegen, da ich es mit einer Client Software im gleichem Netzwerk auch schaffe eine email zu verschicken. Ich muss aber "STARTTLS" als Connection einstellen.
Hat jemand einen Tipp welcher kostenloser SMTP Server brauchbar ist!?
Edit:
Habe es gerade noch mit Yahoo Mail versucht. Da geht das Versenden von emails. Jedoch kann man beim MailFrom keinen Alias dazu geben.
Der Server meldet Error 501 zurück.Gibt es da noch eine Möglichkeit?
8
Modulentwicklung / Re: DLOG_FILE_CSV_DEMO, Zeitpunkt wann die Daten gespeichert werden
« am: 23. August 2012, 22:30:11 »
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.
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.
9
Modulentwicklung / Re: DLOG_FILE_CSV_DEMO, Zeitpunkt wann die Daten gespeichert werden
« am: 23. August 2012, 07:55:56 »
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)
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)
10
Modulentwicklung / Re: DLOG_FILE_CSV_DEMO, Zeitpunkt wann die Daten gespeichert werden
« am: 22. August 2012, 08:31:17 »
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:
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!
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]
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!
11
Modulentwicklung / Re: DLOG_FILE_CSV_DEMO, Zeitpunkt wann die Daten gespeichert werden
« am: 19. April 2012, 13:06:50 »
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!
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!
12
Modulentwicklung / Re: DLOG_FILE_CSV_DEMO, Zeitpunkt wann die Daten gespeichert werden
« am: 18. April 2012, 11:32:12 »
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:
DLOG_SENSOR_DATA:
Ergebnis:
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.
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:
Code: [Auswählen]
(* 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:
Code: [Auswählen]
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:
Zitat
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.
13
Modulentwicklung / Re: DLOG_FILE_CSV_DEMO, Zeitpunkt wann die Daten gespeichert werden
« am: 12. April 2012, 10:08:03 »
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.
[gelöscht durch Administrator]
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.
Zitat
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]
14
Modulentwicklung / DLOG_FILE_CSV_DEMO, Zeitpunkt wann die Daten gespeichert werden
« 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!
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!
15
oscat.lib fuer PC WorX/MULTIPROG / Re: INI_PARSER_FILE Network Lib 1.21
« am: 15. März 2012, 10:55:58 »
Danke für den Hinweis!
Mit der Demo wird die 'config.ini' eingelesen. Auch meine 'Sensors.ini' funktioniert.
Danke!
Mit der Demo wird die 'config.ini' eingelesen. Auch meine 'Sensors.ini' funktioniert.
Danke!
Seiten: [1] 2