# Raspberry Pi 3  - sporadischer Ausfall Profinet...



## Alex vs. SPS (11 März 2018)

Hallo zusammen.

Vielleicht schaut sich jemand von euch die angehangenen Bilder an und hat sofort eine Idee...

Kurz zu meiner Problematik; Ich mache aktuell meine ersten "Schritte" mit Codesys (...jetzt 3.5 SP12 Patch 1) und einem Pi 3 (...seit eben auf 3.5.12.10, vorher 3.5.10.0), welcher über Profinet mit 3 ET 200SP I/O Stationen kommuniziert. Das funktioniert soweit auch alles ganz gut, bis auf eine "Kleinigkeit"...

Sporadisch kommt es zu einem kurzweiligen Ausfall der Profinet Kommunikation (Zeit von Ausfall bis zu erneuter Kommunikation ca. 3-4 Sekunden, passiert vielleicht 3-4 mal wöchentlich - m.E. nach keine wiederkehrenden auffällige Umgebungszustände, die zum Ausfall führen...), welches sich darin widerspiegelt, das alle Ausgänge auf 0 geschrieben werden. Eins vorab; Es handelt sich nur um meine zukünftige Haussteuerung, nicht um irgendwelche "kritischen" Maschinen- und Produktionsabläufe, bei denen durch die Unterbrechung kritische Zustände eintreten könnten.

Aktuell liegen auch noch provisorische 0-8-15 Ethernet Leitungen, diese werden noch durch CAT 7 Leitungen ersetzt. Ich könnte mir auch durchaus vorstellen, das die Problematik in schlechter Schirmung etc. begründet liegt. Wie auch immer. Da ich vorher mit Profinet wenig bis gar nichts zu tun hatte und auch Codesys Anfänger bin, würde mich interessieren, welche Task Einstellungen etc. welche Auswirkungen haben können, was der Watchdog genau ist bzw. auslöst wenn er aktiv ist und welche SPS Einstellungen ich ggf. vornehmen kann, damit ein kurzer Kommunikationsausfall nicht alle Ausgänge auf 0 setzt, sondern den letzten Status bis zum erneuten Aufbau der Kommunikation beibehält (E/A aktualisieren im Stop, aktuelle Werte behalten?)...

Eigentlich Ziel ist aber, die Ursache zu bekämpfen, nicht die Folgen zu "glätten"...

Mit dem nun gemachten update habe ich es noch nicht wieder überprüft. Ich gehe allerdings auch nicht davon aus, das die Problematik in Codesys begründet liegt, sondern eher in meinen Kommunikationseinstellungen und oder der aktuellen Leitung. Eigentlich reicht mir eine relativ langsame Kommunikation, die dafür lieber etwas stabiler läuft. Licht an aus und Fenster auf zu benötigen für mich keine super schnellen Zykluszeiten. Regler etc. laufen auf dem PI nicht...

Vielleicht hat ja jemand von euch schon einen größeren Erfahrungsschatz auf dem Gebiet und kann mir helfen. Ich würde mich sehr freuen.

Gruß,
Alex


----------



## HausSPSler (11 März 2018)

Hi,
ich würde den Send Clock im Slave auf 4ms Task stellen oder aber die IOTask auf 1ms...
Grüße


----------



## Alex vs. SPS (11 März 2018)

*...*

Erstmal vielen Dank für das schnelle Feedback!

Handelt es sich um die unten in den Bildern markierten Einstellungen?

Die Einstellung der Send Clock habe ich versuchsweise schon einmal auf 8 Millisekunden hochgenommen, das konnte den sporadischen Ausfall leider nicht eliminieren. Könnte eine weitere Erhöhung auf 16 evtl. noch etwas bringen?

Was genau bewirkt es, wenn ich den io Task auf 1 Millisekunde stelle?

Gruß,
Alex


----------



## HausSPSler (11 März 2018)

Hi,
der Sendetakt würde ich erst mal gleich setzen wie die IOTask also mach einfach mal den Default 1ms bei beidem, mit der Reductio Ratio dann eher hoch... (hast du ja)
https://help.codesys.com/webapp/_pn...finetIO_Configuration_Editor;version=3.5.12.0
Schritt 2 würde ich dann einfach mir die Diagnose anschauen wenn es passiert, also im SPS log schauen on der Stack was reportet + bei den Slaves die Diagnose anschauen.
https://help.codesys.com/webapp/_pn...finetIO_Configuration_Editor;version=3.5.12.0
dann hier noch die Provider States aktivieren und dann eben auch im Fehlerfall anschauen.

Grüße


----------



## Alex vs. SPS (11 März 2018)

Kann es evtl. auch hilfreich sein, den Watchdog zu aktivieren und die Zeit auf meinetwegen 500 Millisekunden hoch zusetzten. Wenn ich es bis hierher richtig verstehen, würde ein Ausfall in der Kommunikation kleiner 0,5 s dann ja "ohne Folgen" bleiben, oder?

Ich versuche zu verstehen, welche Einstellung welche Auswirkungen hat, interessiert mich...

Was bringt es, die Einstellung "E/A aktualisieren im Stop" zu aktivieren und dann "aktuelle Werte behalten" anzuwählen? Würde das beim "Ausfall" dafür sorgen, das die Feldbusstationen ihren Output Status behalten?

Die Diagnose werde ich mir anschauen (...wird aber vermutlich nach dem Update auf 3.5.12.10 leer sein fürchte ich...). Bisher habe ich das Update nur auf meinem Versuchs-Pi 3 durchgeführt. Kann ich mit Codesys 3.5 SP12 Patch1 auch auf einen Pi 3.5.10 zugreifen und mir die Diagnose anschauen? Diese Version ist aktuell noch in den anderen Raspis. Ich probiere die Dinge immer lieber in Ruhe aus, bevor ich dann alles "hochrüste". Vielleicht unbegründet, aber aus der Erfahrung heraus schadet es oftmals nicht...

Gruß,
Alex


----------



## Thomas_v2.1 (11 März 2018)

Ich weiß nicht wie das bei Codesys bezeichnet ist, aber eigentlich ist soweit ich weiß der Watchdog immer aktiv, und wird als vielfaches des Aktualisierungszyklus angegeben und an das PN-Device übermittelt.
Mal als Beispiel: du hast einen Aktualisierungszkylus von 10ms und einen WatchdogFactor von 3, dann geht das Device in Fehlerzustand wenn es für 30ms in den Fehlerzustand (d.h. Device setzt seine Ausgänge auf Null, Controller sagt die Ausfall des Device). Wenn du den Faktor hochsetzt, dann ist dein PN-Netzwerk nicht mehr so empfindlich auf kurze Störungen oder Überlastungen, aber auch nicht mehr so deterministisch. Ich würde bei so einer Haussteuerung den Aktualisierungszyklus doch auf 50 oder 100ms setzen. das stört dort doch überhaupt nicht.


----------

