WAGO 750-880 hängt sich unvorhersehbar auf, wie grenze ich den Fehler ein?

[Rewe2000]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo liebe Forengemeinde,

ich habe da ein großes Problem, wobei ich eure Hilfe benötige. Einige Forenbeiträge mit ähnlichen Fragestellungen habe ich im Forum gefunden, diese beschreiben aber mein Problem nicht korrekt, weshalb ich hier einen eigenen Forenbeitrag erstelle.

Ich erstelle derzeit auf einen WAGO 750-880 Controller ein größeres Projekt für eine Garten Beregnungssteuerung mit 22 Gießbereichen, SMTP Mailbenachrichtigung und .CSV Datenausgabe auf Speicherkarte des WAGO Controllers mit senden auf den Fritz-Box Router über FTP.

Grundsätzlich läuft mein Programm fehlerfrei und führt auch alle gewünschten Vorgänge über mehrere Tage aus, doch irgendwann (nicht vorhersehbar) hängt sich der Controller auf (MS, NS, I/O, USR blinken 5 x rot) und der Controller ist über Netzwerk und CoDeSys nicht mehr erreichbar. Nach Spannung aus/ein fährt der Controller problemlos hoch und arbeitet das Programm wieder fehlerfrei ab. Der gleiche Fehler kommt in nicht vorhersehbaren Zeitabständen (3-20 Tagen) wieder, unabhängig davon ob ein RESET (Ursprung) durchgeführt wurde oder nicht. Nach Aussage des WAGO Supports kommt hierfür eine Division durch 0 oder das Beschreiben eines Arrays außerhalb der Deklaration in Frage.

Ich selbst vermute den Fehler im Programmteil für das schreiben und senden der .CSV-Dateien. Der Programmteil arbeitet (für mich) ohne erkennbaren Fehler, da dieser über Wochen mehrere CSV-Dateien auf der WAGO Speicherkarte erstellt, diese zum FTP-Server sendet und dann auf der WAGO Speicherkarte auch wieder löscht. Doch irgendwann hängt sich die Steuerung wieder auf und ich kann nach dem diese wieder mit CoDeSys erreichbar ist keinerlei Fehler mehr erkennen.

Wie kann ich die Eingrenzung des Fehlers vernünftigerweise angehen, welche Tipps und Hilfsmittel könnt ihr mir geben um den Fehler zu finden. Ich bin schon so weit, dass ich mir überlege bestimmte Variablen zur Kontrolle in eine CSV-Datei zu schreiben, damit deren Zustand/Werte nach einem Aufhängen noch geprüft werden können.

Hinweis: Beim Übersetzten des Projektes werden in CoDeSys keine Fehler und keine Warnungen angezeigt, ich verwende den FTP-Client WagoLibFtp.lib 2.12.10 und SysLibFile.lib 2.12.10. Das Programm habe ich gemäß der WAGO Dokumentation „a114100d_f„ aufgebaut, jedoch stark für meine Zwecke angepasst. Neueste Firmware für den 750-880 (Firmware revision 01.06.19 (09)) on Board.

Ich freue mich über jeden Hinweis, denn mittlerweile zweifle ich schon an mir selbst.

Gruß
Reinhard

 

[computershooter]

mach mahl im TASK das program langsamer (naja die anrufzeit hoher machen).
sicher sein das die stack nicht vollauft.
seht alle variabelen nach ob die nicht uberlaufen konnen (das heisst 0 werden).

 

[Rewe2000]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Paul,

vielen Dank für deinen Tipp, ich werde die Tasklaufzeit mal ein wenig verlängern und dann sehen, ob der Fehler wieder auftritt.
Im Anhang habe ich mal meine aktuelle Taskauslastung angehängt, ich denke grundsätzlich sollte es so funktionieren, nehme aber Erfahrungen und Verbesserungen von euch gerne an.



Anbei die Beschreibung der Taskkonfiguration:

PLC_PRG	T#200ms	Priorität 9	unter diesen laufen die meisten Programme
Protokolltask	T#1m	Priorität 20	schreibt die Messwerte und Zustände alle Minuten in das Messwert Array
Astronomie	T#30m	Priorität 30	berechnet Sonnenstand etc.
Alarm_Task	T#200ms	Priorität 15	für Anzeige, Darstellung der Alarmmeldungen in der Alarmkonfiguration
Regenmenge	T#20ms	Priorität 5	holt Impulse an einer Digitaleingangskarte ab

Eine Nachfrage habe ich noch zu deiner Antwort, wie meinst du das im letzten Satz?
Wie kann ich nachsehen ob die Variablen nicht überlaufen?

Ich habe mein Bytearray schon sehr großzügig angelegt, auch im ungünstigsten Fall sollte dieses für alle Werte ausreichen. Wird dieses zu klein bemessen, so werden die folgenden Variablen gnadenlos überschrieben, diese Erfahrung habe ich auch schon hinter mir.

Nochmals Danke von meiner Seite und viele Grüße nach NL
Reinhard

 

[HausSPSler]

Hi,
ich würde mal in der Hilfe nach checkbounds suchen.
So vorgehen:
folgende Funktion hinzufügen (musst die nicht aufrufen, das System ruft die Implizit auf wen vorhanden im Projekt)
dann damit online gehen und zwei Brakepoints setzen (einmal für den Fall das das Array unten und oben überschritten wird...)
Klar nun lässt du CODESYS online verbunden bis es passiert.
FUNCTION CheckBounds : DINT
VAR_INPUT
index, lower, upper: DINT;
END_VAR

IF index < lower THEN
CheckBounds :=
lower;
ELSIF index > upper THEN
CheckBounds := upper;
ELSE
CheckBounds := index;
END_IF

Wenn also nun der Fehler (also jemand auf ein Array Element außerhalb des Index greift) dann steht CODESYS auf dem Brakepoint und du hast die Stelle wo es genau in deinem Projekt passiert.

das kannst du mit den anderen Checkfunktionen auch machen...
Grüße

 

[Rewe2000]

Hallo Edwin,

vielen Dank auch Dir für den Tipp mit checkbounds, ich habe diese Funktionen schon in der Hilfe gefunden, aber ehrlich gesagt habe ich diese als Anfänger nicht so recht verstanden und somit auch nicht angewendet.

Verstehe ich das richtig, die checkbounds Funktion ohne Breakpoints verhindert, dass Grenzen außerhalb des Arrays beschrieben werden. Adressiere ich auf einen nicht vorhandenen Index, so wird bei vorhandensein von checkbounds der Wert in den obersten noch gültigen Index abgelegt. Das gibt zwar keinen Sinn für das erwünschte Ergebnis, verhindert aber einen "Überlauf" von Arrays.

Ich habe das angegebene Beispielprogramm in der Hilfe mal simuliert, es arbeitet genau so wie beschrieben. Bei vorhandensein von checkbounds wird der auf [10] adressierte Wert in [7] (ARRAY[0..7]) abgelegt, ohne Fehlermeldung. Ohne vorhandensein von checkbounds dagegen wird eine Fehlermeldung ausgegeben und das Programm geht in der Simulation in Stop.

Die Breakpoints lege ich in der Funktion checkbounds selbst an, somit sehe ich dann, ob das Array außerhalb der gültigen Grenzen beschrieben wurde.
In der Simulation hat es prima funktioniert, ich konnte den Fehler gut erkennen.

Vielen Dank für die hilfreichen Ansätze zur Problemlösung, es hilft mir gut den Fehler endlich einzugrenzen.
Reinhard Wechsler

 

[oliver.tonn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Schön das Dir hier jemand weiterhelfen konnte, aber bitte gib Du auch Rückmeldung, wenn Du die Ursache gefunden hast und welche es war, damit könntest Du dann wiederum anderen helfen.

Von irgendwas mit Internetzugang gesendet.

 

[Rewe2000]

Sicher melde ich mich wieder wenn ich die Ursache gefunden habe, aber es könnte schon einige Wochen dauern, da der Fehler ja nur sehr sporadisch und selten auftritt. Damit wird es nicht leichter diesen zu finden.

Gruss Reinhard

 

[Anton234]

Hallo Reinhard,
ich hab auf meiner Wago 750-880 selbiges Problem. Nutzt du ebenfalls den Wago Datalogger/Plotter um Daten auf der Sd-karte abzulegen?
Mein letzter Versuch war es, jeden Tag ein neues CSV anzulegen - bisher läuft die Anlage noch.
Bin dem Problem leider auch noch nicht auf die schliche gekommen.
Grüße

 

[Rewe2000]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Andy,

schön zu hören, dass es nochmal jemand mit dem gleichen Problem gibt, somit steigen die Chancen für uns beide, dass wir die Ursache für den Fehler finden können.

Ich verwende den "FTP_CLIENT" aus der WAGO "WagoLibFtp.lib", mein Programm habe ich abgeleitet aus einem Beispielprojekt aus einem WAGO Lehrgang über eine Boilersteuerung mit CSV-Ausgabe. Ich vermute auch die Fehlerursache im Programmteil mit den Arrays, entweder das CSV Datensammeln und Datehandling oder der Bereich welcher Fehlermeldungen an eine Mailadresse sendet.

Das Programm habe ich wie folgt modifiziert:
Ich sammle die Daten in ein Array und schreibe diese 4 mal täglich mit "append" auf die SD Karte, so erhalte ich eine Datei pro Tag mit den gesammelten Meßwerten. Nachdem die datei voll ist, sende ich diese zum FTP Server meiner Fritz-Box. Die Dateien auf der SD Karte werden wie in einem Ringspeicher gehalten und die ältesten Dateien vom Programm wieder von der SD Karte gelöscht.

Nachdem mein Fehler nur sehr selten und hochsporadisch auftritt werde ich mal als erstes den Tipp von Edwin umsetzen. Da ich nicht Wochenlang rund um die Uhr mein CoDeSys laufen lassen kann, werde ich mal versuchen einige Variablen bei auftreten des Fehlers mit CheckBounds zu sammeln und diese RETAIN PERSISTENT abzulegen, in der Hoffnung nach dem Spannung aus/ein sind Daten noch vorhanden. Somit könnte ich sehen ob wirklich die Arrays außerhalb der Grenzen beschrieben werden.

In Verdacht habe ich auch noch den Programmteil mit den "SMAIL_Client2", ich hatte den Eindruck der Feler wäre häufiger aufgetreten als mehrere Alarmmeldungen pro Woche versendet wurden. Jetzt da mein Projekt ziemlich "rund" läuft gibt es nahezu keine Fehler mehr und die Abstürze der Steuerung halten sich damit auch in Grenzen. It aber bei einer Bewässerungssteuerung sehr ärgerlich, wenn man sich nicht 100% darauf verlassen kann.
Ist schon irgendwie seltsam, das Projekt läuft mehrere Wochen ohne irgend welche Probleme, mit Sicherheit werden alle Programme in dieser Zeit mehrmals ohne Probleme durchlaufen und irgendwann aus heiterem Himmels ist die Steuerung wieder abgestürzt. Dachte nach dem Firmwareupdate auf die Version 9 wird es besser, aber der Fehler ist erneut einmal wieder aufgetreten.

Ich gebe die Hoffnung nicht, auf irgendwann im Winter den Fehler zu finden. In dieser Zeit braucht die Steuerung nicht zu gießen und somit können die Programme mal so verändert werden, damit ich den Fehler hoffentlich provozieren kann, ohne die Gefahr, dass mir die Pflanzen vertrocknen.

Gruß Reinhard

 

[wat84]

Hallo,

in welchem Task schreibst du die CSV? Dateioperationen sollen im Task mit der niedrigsten Priorität ablaufen.

 

[Anton234]

Hallo,

bei mir läuft im Moment noch alles in einer Task. Ich nutze den

• Wago Datalogger (CSV-Datenerstellung und speichern auf Sd-karte)
• 3 Betriebstundenzähler die eine Text_Datei als Ablage erzeugen
• Wago SMailClient ( Text-Versand - hier werden vor allem große String-Daten gehandelt (>255 - 512 Zeichen)

Mein Verdacht lag in erster Linie auf der Sd-karte. Da hier das Programm drauf liegt und Gleichzeitig Daten von mehreren Richtungen abgelegt werden.
@ wat84: Sollte dann jede CSV-Datei einen eigenen Task geschrieben werden?

 

[wat84]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

mir hat Wago am Telefon gesagt, dass mehrere Datenlogger in einer Task laufen können und das Dateioperationen immer am niedrigsten priorisiert sein sollten.
Getestet habe ich es mit mehreren Datenloggern bisher nicht.

 

[Rewe2000]

Hallo,

bei mir ist bisher der CSV-Task nicht mit der niedrigsten Priorität gelaufen, da ich noch einen sehr Rechenintensiven Sonnenstandsbaustein verwende, welchen ich alle 30 Minuten mit einen eigenen Task starte (siehe meine Tabelle den Task's). Werde mal versuchen den CSV-Task die niedrigste Priorität zu geben und dann sehen, ob sich die Steuerung wieder aufhängt.

@Hallo Andy
Grundsätzlich solltest du in jeden Fall CSV-Operationen in einem eigenen Task laufen lassen und darauf achten, dass die Priorität niedriger als bei den "wichtigen" Programmen eingestellt ist. Optimal ist natürlich die niedrigste Priorität.

Gruß Reinhard

 

[Rewe2000]

Hallo,

ich denke ich habe die Ursache für mein "Aufhängen" der Steuerung lokalisiert. Mit sehr großer Warscheinlichkeit habe ich den "FTP_CLIENT" in Verdacht, aus folgenden Grund:

Wenn ich nichts am Programm geändert habe und deshalb die Steuerung nicht neu laden musste trat der Fehler über Monate nicht auf. Erst nachdem ich wieder Änderungen (absolut unkritische Aktionen) am Projekt begann, hatte ich plötzlich wieder diese ominösen Aufhänger und ich konnte diese mittels Retain/Persistend Variablen näher eingrenzen.

Der Fehler trat genau beim PUT() Aufruf des Bausteins "FTP_CLIENT" auf, obwohl alle übergebenen Parameter (Dateinamen) 100%'ig korrekt waren. Ich konnte den Fehler, bei mehreren Versuchen, immer an der gleichen Stelle reproduzieren. Alle anderen Aufrufe des Bausteins "FTP_CLIENT" machten keinerlei Probleme, nur beim PUT(), den senden der FTP-Datei, hängte sich der Controller auf. In den Variablen, welche ich zur Beobachtung eingerichtet hatte wurde als Fehler "FTP_Invalid_Parm" angezeigt, obwohl der FTP-Server erreichbar und die übergebenen Parameter absolut korrekt waren.
Erst nach "Reset-Ursprung" lief der FTP-Datentransfer wieder problemlos, ohne dass ich irgend eine Änderung am Projekt gemacht hätte.

Da mir diese Situation für eine Beregnungssteuerung zu kritisch war habe ich nun den FTP-Teil und das Datensammeln anders gelöst. Ich will nicht das Risiko eingehen, die Steuerung hängt sich plötzlich auf und alle Pflanzen sind vertocknet bis ich es mitbekomme.

Ich stelle nun die Daten, welche ich auswerten will, als Merker bereit und hole diese über einen Raspberry PI 3 mit Fhem über Modbus ab. Das klappt bisher sehr gut und ich habe den großen Vorteil ich kann mir die übergebenen Daten (Regenmenge etc.) sofort in einen Plot ansehen. Die WAGO ist somit frei für die eigentlichen Aufgaben.

Diese Erkenntnis hilft zwar anderen nicht weiter, dass ich keine Lösung für das Problem gefunden habe, aber zumindes sollten andere User sich mal den FTP_Client bei änlich gelagerten Problemen näher ansehen.

Gruß
Reinhard

 

[Anton234]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Reinhard,

mein Programm lief jetzt etwa 140 Tage bis meine Web-Visu nicht mehr zu erreichen ist (weder über die App noch über den Browser). An die WBM-Seite komm ich auch nicht mehr ran.
Das Programm läuft im Hintergrund munter weiter und ruft fleißig Wetterdaten ab und sendet mir täglich eine Statusmeldung per Mail.
Den FTP-Client nutze ich bei mir nicht. Die Files rufe ich direkt mit dem FileZilla ab.

Ich werde jetzt mal noch auf die Fw10 umsteigen und dort das ganze wieder neu aufsetzen...

Gruß

 

[Rewe2000]

Hallo Andy,

das sind wiklich blöde Fehler!

Bei dir wirkt sich der Fehler aber anders aus, an meiner Steuerung blinkten (MS, NS, I/O, USR - 5 x rot) und ich konnte diese über Netzwerk überhaupt nicht mehr erreichen, auch nicht mehr mit CodeSys, die WAGO war definitiv in STOP. Erst nach einem Stop -> Start (mit dem Schiebeschalter, unter der kleinen Klappe) war sie wieder erreichbar und die Remanenten Variablen waren noch vorhanden.

Ich habe auch bemerkt, immer wenn Fehler angestanden waren (wegen dem aufgehängten "FTP_Client", wurden diese auch über den Mail_Client als Mail versandt. In dieser Zeit sind die Abstürze deutlich häufiger aufgetreten, ursprünglich zählte der Mail_Client auch zu meinen verdächtigen.

Kannst du denn die WAGO noch anpingen?

Ich konnte Remanente Variablen in die Programmteile schreiben und diese dann nach einem Neustart einsehen, da der Inhalt noch vorhanden war konnte ich erkennen, dass der Absturz immer bei dem PUT() Aufruf des FTP_Client erfolgte.

Den Mail_Client habe ich noch auf der Steuerung, bisher gab es aber nur wenige Fehlermeldungen und keinerlei Abstürze mehr, ich hoffe es bleibt auch so.

Ich hoffe du bekommst den Schuldigen zu fassen!
Gruß Reinhard

 

[Anton234]

Hallo Reinhard,

mittlerweile ist der Fehler wieder aufgetaucht (Laufzeit etwa 100 Tage). Der Zugriff auf die WBM-Seite funktioniert noch und der Controller arbeitet, jedoch kann ich die Visu nicht mehr öffnen.
Beim Versuch Daten mit dem FileZilla von der Sd-Karte (Wago-Sd) zu holen wird mir stattdessen der Inhalt der PLC angezeigt.

Beim Versuch das Versuch das Projekt im Codesys neu zu laden kommt der Fehler das nicht alle Visu-Seiten übertragen werden können. (Fehler beim Schreiben der Datei xyz..)

Gibt's für dieses Verhalten eine Erklärung?
Grüße

 

[Rewe2000]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Andy,

ich denke fast, bei dir gibt es Probleme mit dem Speicher. Das würde erklären weshalb das WBM und die Steuerung noch läuft. Der Fehler "nicht alle Visu-Seiten können übertragen werden" deutet für mich auf zu wenig verfügbaren Speicherplatz hin. Es könnten auch alte "Dateileichen" noch auf der Steuerung liegen, welche beim laden des Projektes den Platz blockieren.

Ich würde an deiner Stelle mal folgendes versuchen, ein lauffähiges Projekt am PC unter CodeSys natürlich wird vorausgesetzt.

1. Alle nicht flüchtigen wichtigen Einstellungen per Screnshot sichern.
2. Mit WAGO Ethernet Settings das Dateisystem der Steuerung zurücksetzen. Achtung!!! Alles auf der Steuerung ausser die Firmware wird gelöscht!
3. Eine vorhandene Speicherkarte neu formatieren.
4. Das komplette Projekt, nach alles bereinigen und neu übersetzen wieder in den Controller laden.

Sollten die genannten Fehler erneut wieder in gleicher Weise auftreten könnte dies nach meiner Meinung auch an einen fehlerhaften Speicherbaustein liegen.

Befindet sich bei dir das Projekt in der Steuerung oder auf der SD-Karte?

Ich habe seit einigen Monaten mein Projekt mit der Visu auf die SD-Karte ausgelagert, das der interne Speicher des 750-880 zu klein wurde, bisher habe ich damit nur beste Erfahrungen gemacht.

Ich hoffe auch du bekommst dein Problem in den Griff.

Gruß Reinhard

 

[Anton234]

Hallo,
beim Versuch die Daten des Datenplotters nach der Formatierung auf die Sd-Karte zu kopieren (Schreiben) ist bei mir am Rechner die Meldung aufgetaucht: Das Zeitlimit für Semaphore wurde erreicht. Wodurch der Kopiervorgang abgebrochen wurde.
Eine Schnellformatierung hat hier leider auch keine Abhilfe geschaffen - nachdem standardmäßig formatiert wurde hat das kopieren wieder geklappt.
Nun hab ich die Schritte wie von dir beschrieben durchgeführt - das Projekt läuft jetzt wieder auf der Sd-Karte.
Bei der Durchsicht der Log-Daten ist mir aufgefallen, dass nach etwa 100 Tagen das Logfile nur noch die erste halbe Stunde eines Tages enthält (anstelle der 24h) und danach leer ist. Die SPS erzeugt munter jeden Tag ein neues LogFile - hört aber nach einer halben Stunde wieder auf damit! Der Intervall des Loggers beträgt 1 Minute. Der Task läuft mit 1s zyklisch Prio 25.
Gruß

 

[Tobsturbo]

Hallo ,
ich habe einen vergleichbaren Fehler und zwar verschwindet der Dateiordner, also CSV_Files auf der SD-Karte. Die ersten 5 Tage läuft alles ganz normal, nach einigerzeit läuchtet die LED der SD karte druchgehend(Write LED)
Da es sich um eine Industrieapplikation handelt ist dieser Fehler schon sehr kritisch.

Wie schnell sollte eigentlich die Task geschwindigkeit sein ? und Welche Priorität sollte für den Task verwendet werden ? Gibt es da Erfarungen .
Das ganze System läuft unter Codesys 2.3 Datalogger V2.0 ist installiert (zu nachherigen ansicht im Browser)
verwendete LIB:
WAGO_Datalogger_02.lib


Interessant wäre noch zu wissen wie viele Dateien denn Maximal in einem Ordnerabgespeichert werden dürfen ?
Das habe ich gerade im Comment in Der WAGO_Datalogger_02.lib
- number of files stored under main folder of SD-card is limited (FAT). (relevant only for 750-88x and PFC)
Wenn es daran liegen sollte würde ich für jeden Tag oder jedem zweiten Tag einen neuen Ordner erstellen.


Ich hoffe mir kann jemand weiter helfen.