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.


Themen - skateman

Seiten: [1]
1
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...





2
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?

3
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).




4
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

5
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...



6
BECKHOFF / String via UDP-Message senden
« am: 12. Juni 2012, 16:06:55 »
Hallo,

ich würde gerne von meiner Beckhoff CX einen String via UDP-Message (Port 2157) an einen Router senden, welcher aufgrund des Inhalts dann bestimmte Handlungen durchführt.

Im Prinzip müsste das doch ziemlich so wie in dem Anwendungs-Beispiel der OSCAT-Doku für den IP-Control Baustein funktionieren (natürlich mit richtigem Port und IP-Adresse), oder irre ich mich da? Ich habe den Router noch nicht, deshalb kann ich es nicht testen und wollte vorher mal fragen...

lG
Roland

Seiten: [1]