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.


Nachrichten - skateman

Seiten: [1] 2
1
BECKHOFF / Re: DLOG_STORE_FILE_CSV - Zeilenumbruch
« am: 13. Juli 2015, 19:32:08 »
Dass das Logging dann erst mit einem kurzen Delay nach Sperre/Freigabe de DLOG_STORE_CSV-Bausteins beginnt, wäre bei meiner Applikation kein Problem.

Ich habe aber grade gesehen, dass die Änderung die Wirkung verfehlt, da der Vergleich von n mit X.ID_MAX ja dann erfolgt, wenn step_2 = 0 ist.

Wenn ich das richtig interpretiere, wird X.UCB.D_HEAD auf 0xEE00 gesetzt, wenn ENABLE false wird. In der CASE-Anweisung step_2 gibt es in der WHILE-Schleife eine Abbruchbedingung: wenn X.UCB.D_HEAD=0xEE00 ist, wird step_2=10. Demnach dürfte das Problem mit dem Überlauf von n gar nicht passieren. Aber D_HEAD wird doch vom zuvor aufgerufenen UCB-Baustein überschrieben, wenn DATA.BUF_COUNT > 0 ist, oder? Dann würde das File auch erst geschrieben werden, wenn das zeitgesteuerte Schreiben aktiv wird. Kann das sein?



2
BECKHOFF / Re: DLOG_STORE_FILE_CSV - Zeilenumbruch
« am: 13. Juli 2015, 15:02:56 »
Hallo peewit,

ich habe mir grade überlegt, ob das nicht die sauberere Lösung wäre:

CASE step_1 OF

00: IF ENABLE AND step_2 = 0 THEN
n:=0;
aw_enable := AUTO_CLOSE >= T#5s;
wd_time := SEL(X.LOAD_TIME_MAX > T#0s, T#5ms,X.LOAD_TIME_MAX);
fn_last := fn; (* aktuellen Dateinnamen speichern *)

X.ID_MAX := USINT#00;
X.ADD_COM := 01; (* ADD INFO *)
X.STORE_TYPE := BYTE#2; (* CSV-Modus *)
step_1 := 10;


Nur wenn step_2 gleich 0 ist (Schreibvorgang beendet), wird der erste Schritt von step_1 ausgeführt und somit mit neuem Logging bzw. Initialisierung (inkl. Rücksetzung von X.ID_MAX) begonnen. Das hätte auch den Vorteil, dass man die Anzahl der Sattelitenbausteine/DLOG-Bausteine per Online-Change ändern könnte, wenn ENABLE auf FALSE gesetzt ist. Habe ich noch irgendeine Falltür übersehen?
Bei meinen Tests hats zumindest funktioniert...

3
BECKHOFF / Re: DLOG_STORE_FILE_CSV - Zeilenumbruch
« am: 10. Juli 2015, 14:58:48 »
Hi,
das wäre eine Möglichkeit...
In dem Code ist allerdings ein ":" nach X.ID_MAX zu viel.  ;)

4
BECKHOFF / Re: DLOG_STORE_FILE_CSV - Zeilenumbruch
« am: 08. Juli 2015, 10:46:05 »
Hallo,

die Bausteine werden zyklisch aufgerufen und unterliegen auch keiner Bedingung.

So werden die Bausteine in meinem Programm aufgerufen (LOG_Durchluss und LOG_Durchluss_Zaehler_Tag sind DLOG_REAL Bausteine):

DLOG_DT(
FMT:=,
COLUMN:='Datum/Zeit' ,
DELTA:= ,
X:=X );

LOG_Durchfluss(
VALUE:=MAIN.Durchfluss.MW ,
N:= 1, (*Nachkommastellen*)
D:='.' ,
COLUMN:= 'Durchfluss.Messwert',
DELTA:=5 ,
DELTA_ONLY:= TRUE,
MIN_DELAY:= t#10s,
X:= X);

LOG_Durchluss_Zaehler_Tag(
VALUE:=MAIN.DFL_Zaehler.Zaehlerstand_Tag ,
N:= 0, (*Nachkommastellen*)
D:='.' ,
COLUMN:= 'DFL_Zaehler.Zaehlerstand_Tag',
DELTA:=1 ,
DELTA_ONLY:= TRUE,
MIN_DELAY:= t#1m,
X:= X);



DLOG_STORE_FILE_CSV(
ENABLE:=Filename <> '' AND DLOG_FILE_TO_STRING.FILE_COUNT < 100 , (*Es wird nur aufgezeichnet, wenn die Freigabe gesetzt ist und weniger als 100 Files im Buffer vorhanden sind*)
TRIG_M:= TIMER_INIT_SAVE.Q,
TRIG_T:= ,
FILENAME:=Filename ,
DTI:= Uhrzeit_Lokal,
SEP:= 59,   (*ASCII-Zeichen für ;  *)
AUTO_CLOSE:=t#5m, (*in diesem Intervall wird das File zwingend gespeichert*)
RETAIN_DATA:=MAIN.DLOG_RETAIN,
X:= X,
ERROR_C=> ,
ERROR_T=> );

Hier noch der Code vom abgeänderten DLOG_REAL Baustein:
TIMER_delay(IN:=TRUE, PT:= MIN_DELAY); (*Mindestzeit zwischen zwei Wertänderungen*)

CASE x.ADD_COM OF

01: (* ADD INFO *)
X.ID_MAX := X.ID_MAX + USINT#1;
id := WORD#16#0201; (* Quelltype REAL , Zieltype STRING *)
02: (* ADD HEADER *)
X.UCB.D_STRING := COLUMN;
X.UCB.D_HEAD := id;
X.UCB.D_MODE := 1;
UCB(DATA:=X.UCB); (* Daten eintragen *)
value_log:= REAL_TO_STRF(IN:=VALUE,N:=N,D:=D); (*RHC - Wert initialisieren*)
03: (* ADD DATA *)
IF (DELTA_ONLY) THEN
X.UCB.D_STRING := value_log;
value_log:= '';
ELSE
X.UCB.D_STRING := REAL_TO_STRF(IN:=value_last,N:=N,D:=D);
delta_last := value_last;
END_IF
X.UCB.D_HEAD := id;
X.UCB.D_MODE := 1;
UCB(DATA:=X.UCB); (* Daten eintragen *)
04: (* ADD DATA REQ *)
IF DELTA <> 0.0 THEN
IF (VALUE <= (delta_last - DELTA) OR VALUE >= (delta_last + DELTA)) AND TIMER_delay.Q THEN
value_log:= REAL_TO_STRF(IN:=VALUE,N:=N,D:=D);
X.ADD_DATA_REQ := TRUE;
delta_last := VALUE;
TIMER_delay(IN:= FALSE);
END_IF;
END_IF;
END_CASE;
value_last := VALUE;

Ich sehe leider keinen Fehler...

5
BECKHOFF / DLOG_STORE_FILE_CSV - Zeilenumbruch
« am: 07. Juli 2015, 14:51:22 »
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:
Zitat
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;
Statt den Zeilenumbrüchen wird fälschlicherweise ein Separator gesetzt!


So sollte es eigentlich aussehen:
Zitat
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...





6
Hallo,

ich habe ein Problem mit dem DLOG_STORE_FILE_CSV Baustein festgestellt - eigentlich ist es wahrscheinlich eher ein Problem vom FILE_SERVER Baustein.

Folgendes Verhalten:
Wenn man im normalen Logging-Betrieb (.csv-File am Beckhoff CX ist durch den DLOG_STORE_FILE_CSV Baustein geöffnet) die PLC stoppt oder wenn man z.B. einen Online-Reset durchführt, kann auf das File nach anschließendem Start der PLC nicht mehr zugegriffen werden.

Ein Zugriff/Löschen des Files geht dann weder manuell über ftp oder Explorer, noch über das PLC-Programm. Bausteine wie DLOG_STORE_FILE_CSV oder DLOG_FILE_TO_FTP liefern dann die Fehlermeldungen 28 oder 140.

Ein Zugriff/Löschen des Files wird erst wieder möglich, wenn man einen kompletten Neustart der PLC-Runtime durchführt. Die Problemursache liegt vermutlich daran, dass das File bei einem PLC-Stopp nicht ordnungsgemäß geschlossen wird und im Hintergrund geöffnet bleibt.

Ich vermute mal, dass der Kollege aus folgendem Thread das selbe Problem hatte: http://www.oscat.de/community/index.php/topic,1982.0.html

Kann man dieses Problem irgendwie lösen?

7
Hallo,

ich habe gerade den Modbus-Client getestet und dabei einen Fehler in der Doku gefunden:

Bei Verwendung von Functioncode 4 (Read Input Register) muss natürlich auch die Anzahl der zu lesenden Datenpunkte mit R_POINTS definiert werden!

Siehe Anhang - fehlender Eintrag in der Doku-Matrix!


[gelöscht durch Administrator]

8
Alles klar - danke! Das hätte ich auch selbst finden können... :o  :D

9
Hallo,

ich habe das Problem sowohl mit GMX als auch mit A1.

Es gab ja glaub ich einen oscat-Testaccount bei GMX (oscat@gmx.de) - da müsste das Problem ja auch auftreten...

10
Modulentwicklung / Problem mit SMTP-Client in Network LIB 1.30
« am: 27. Mai 2013, 15:43:48 »
Hallo,

ich hatte bisher auf einem Beckhoff CX (TwinCAT) die Network LIB 1.21 im Einsatz. Mit dieser LIB hat der SMTP-Client einwandfrei funktioniert.

Sobald ich allerdings die neue LIB verwende, bekomme ich folgende Fehlermeldungen vom SMTP-Client:
ERROR_T: 0x05
ERROR_C: 0x003200FA --> Schrittnummer 50, Response-Code 250

Bei Schritt 50 wurde ja auch was geändert in v1.30 --> nur wenn auth_state <> BYTE#0 ist, wird der nächste Schritt ausgeführt - auth_state bleibt bei mir aber immer 0x0 - daher wird nicht weitergesprungen...
Wie gesagt - mit der alten Methode funktioniert es aber (getestet mit 2 verschiedenen SMTP-Servern).




11
BECKHOFF / Re: Ping-Ãœberwachung
« am: 18. Oktober 2012, 22:01:43 »
Alles klar - danke!

12
BECKHOFF / Ping-Ãœberwachung
« am: 18. Oktober 2012, 20:02:57 »
Ich habe eine CX mit einem UMTS-Router im Einsatz, wobei ich das Problem habe, dass sich der Router von Zeit zu Zeit aufhängt und über WAN nicht mehr erreichbar ist. Der Router hat zwar selbst eine Ping-Überwachungsfunktion mit koppelbarem Reboot, aber das funktioniert auch nicht immer.

Aus diesem Grund würde ich gerne von der CX aus eine Ping-Überwachung auf eine hochverfügbare IP (z.B. 8.8.8.8 ) ausführen und bei längerem Abbruch der Verbindung einen Öffnerkontakt eines Relais schalten, über welchen die Spannungsversorgung des Routers geführt ist. Somit hätte ich einen sicheren Hardware-Reset.

Ich hätte jetzt keine Möglichkeit gefunden, Pings mittels der network.lib abzusetzen. Ich könnte natürlich auch zyklisch einen HTTP_GET Aufruf auf z.B. google.com ausführen und wenn kein Error ausgegeben wird, ist die Verbindung in Ordnung.

Gibt es noch eine elegantere Lösung?

lG
Roland

13
BECKHOFF / Re: SMTP_Client Alias-Name Fehler
« am: 27. August 2012, 15:48:30 »
zwischen "Station_01" und <oscat@gmx.net>

"Station_01" <oscat@gmx.net> --> FALSCH
"Station_01"<oscat@gmx.net> --> RICHTIG

14
BECKHOFF / SMTP_Client Alias-Name Fehler
« am: 27. August 2012, 15:40:00 »
Ich hatte bisher zum Versenden von mails immer einen GMX-Account verwendet, was auch gut funktionierte.

Nun habe ich aber einen Mail-Account eines anderen Providers verwendet und bei jedem Sende-Versuch die Fehlermeldung '555 5.5.4 unsupported option: <emailadresse@xyzaccount.at>' erhalten, was ich mir nicht erklären konnte, da alle Daten stimmten.

Durch googeln und diverse Versuche habe ich den Fehler nun gefunden:
Das Problem liegt am Alias-Namen --> diesen gibt man ja durch Trennung mit ";" an --> z.B. oscat@gmx.net;Station_01. Der SMTP_Client baut daraus dann folgenden String: 'MAIL FROM: "Station_01" <oscat@gmx.net>'.
Aus irgendeinem Grund mag der Mailserver das Leerzeichen zwischen Alias-Name und Mail-Adresse nicht - ich habe dieses mal entfernt und siehe da, es funktioniert --> 'MAIL FROM: "Station_01"<oscat@gmx.net>'

Vielleicht sollte man das mal ändern...



15
BECKHOFF / Re: String via UDP-Message senden
« am: 29. Juni 2012, 14:34:38 »
 ::) Sorry - war mein Fehler. Habe eine andere CX genommen, auf welcher der TCP/IP-Server nicht installiert war.

Habe ich nun nachgeholt und siehe da: es funktioniert bestens!!! Danke nochmal für das Beispiel-Programm!

Seiten: [1] 2