Step 7 CPU Stop - PROFINET IO: Stationswiederkehr

Fluffi

Level-2
Beiträge
449
Reaktionspunkte
69
Zuviel Werbung?
-> Hier kostenlos registrieren
an einer Anlage, welche seit 1 Jahr ohne Probleme läuft, treten nun hin und wieder folgende Meldungen auf und die CPU geht in Stop.

1.
PROFINET IO: Stationswiederkehr, jedoch Störung/Wartung
Adresse der betroffenen Station: Eingangsadresse: 2016
IO-System-ID: 100
Stationsnummer: 6
Log. Basisadresse des IO-Controllers: 2043
Angeforderter OB: Baugruppenträgerausfall-OB (OB 86)
OB nicht vorhanden oder gesperrt oder nicht startbar im aktuellen Betriebszustand
externer Fehler, gehendes Ereignis
(Kodierung: 16# 38CC FE56 C454 07FB 07E0 8006)

wobei hier mehere Meldungen mit verschienenen Stationensnummer und Eingangsadressen von Profinet-Geräten auftauchen.



2.
Ereignis 3 von 10: Ereignis-ID 16# 1381
Manuelle Neustart (Warmstart)-Anforderung
STOP-Ursache: STOP durch Peripheriezugriffsfehler (OB nicht geladen oder nicht möglich, bzw. kein FRB vorhanden)
Anlaufinformation:
- Anlauf ohne geänderten Systemausbau
- keine Soll-/Istdifferenz vorhanden
- Uhr für Zeitstempel bei letztem NETZ-EIN gepuffert
- Einprozessorbetrieb
Aktuelle/letzte durchgeführte Anlaufart:
- Neustart (Warmstart) durch MPI-Bedienung; letzter NETZ-EIN gepuffert
Zulässigkeit bestimmter Anlaufarten:
- manueller Neustart (Warmstart) zulässig
- automatischer Neustart (Warmstart) zulässig
Letzte gültige Bedienung oder Einstellung der automatischen Anlaufart bei NETZ-EIN:
- Neustart (Warmstart) durch MPI-Bedienung; letzter NETZ-EIN gepuffert
Angeforderter OB: Anlauf-OB (OB 100)
Prioritätsklasse: 27
(Kodierung: 16# 1381 1B64 C772 4563 0814 7714)


Der OB 86 und OB100 sind online.
So wie ich das sehe gehen zu einem bestimmten Zeitpunkt ein Großteil der Geräte am Profinet verloren.
Wenn bei dem Fehler online gehe sind die Geräte aber da. Daher sind sie nur kurz weg.
Was kann die Ursache dafür sein?
Problem mit Siemens Profinet-Switch?
Ist eine Softwareproblem hier auszuschließen?
Wie kann man zumindest den Stop der CPU hier verhindern?
 
Dann brauchst Du denke ich den OB122.

Die Preipherie geht weg wegen dem Teilnehmerausfall, dann geht die CPU in STOPP und kann danach den OB86 nicht starten weil schon in Stopp.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich würde den Fehler suchen und NICHT mit einem OB den Fehler kaschieren.

Auch kann man die Diagnose des Teilnehmers auswerten und dann erkennen, was die Ursache für den Ausfall ist.


bike
 
ich hab das Problem nun genauer analysiert.
Es betrifft immer unterschiedliche Profinet-Baugruppen.
In der CPU Diagnose lässt sich sehen, dass die entsprechenden Baugruppen für ein paar ms nicht verfügbar und dann wieder vorhanden sind.
Ein Spannungsverlust lässt sich mehr oder weniger ausschließen, da ein Reboot der Baugruppen viel länger dauern würde und nicht so extrem kurz wäre.
Daher scheint es ein Problem im Profinet-Netzwerk selber zu sein.
Eine genauere Fehlerbeschreibung kann ich leider nirgendswo herauslesen.

Die Profinet-Aktualisierung war, wie standardmäßig immer eingestellt und auch sonst nicht problematisch, bei 1ms (weniger geht auch nicht).
Diese habe ich auf 2ms erhöht, was eigentlich auch noch sehr sportlich ist.
Zudem habe ich bei allen Profinetgeräten die Anzahl der nicht beantwortbaren Pakete auf 20 erhöht (Standard ist 6), was eine Ansprechüberwachung von 40ms darstellt.
Der CPU Zyklus liegt bei ca 20ms. An der Anlage selber ist nichts was auch nur annähernd Richtung "Echtzeit" geht.
Seit der Umstellung trat der Fehler nicht mehr auf.

Ich habe zudem alle Profinetkabel und Stecker überprüft. Hier konnte ich nichts feststellen.

Daher meine Fragen:
Ist meine Reaktion auf das Problem die richtige? Ist es normal, dass bei ca.20 Profinet-Teilnehmern solche Probleme mit dem Bus auftreten können?
Wie sind eure Profinet Einstellungen des Buses und der Geräte? Gibt es sonst noch etwas, das ich überprüfen oder umstellen könnte?
Sind die oben genannten Profinet-Parameter eigentlich immer noch zu "hart". Sollte ich diese noch weiter erhöhen?
Evtl. hab ich dann noch den Siemens Profinet Switch (unmanaged) im Verdacht. Ist es wahrscheinlich das der einen Macken haben könnte?

Die obige Betrachtungsweise wäre eine Art von "Busüberlast" als Fehlerbild. Die Alternative Fehlerursache wäre, dass ein Gerät den Bus stört.
Aber wie ließe sich das herausfinden?
Was meiner Meinung nach aber gegen diese Störung spricht ist, dass Geräte die getrennt am Switch hängen betroffen sein können. Ein Switch
gibt ja in der Regeln Probleme auf einem Knoten/Busabschnitt nicht weiter auf die anderen Ports.

Abschließend sei noch gesagt, das Netzwerk ist ein reines Profinet-Netzwerk. Es gibt keinen PC oder sonstiges Gerät, welches über das normale
TCP/IP Protokoll den Bus in Anspruch nimmt.
 
Zuletzt bearbeitet:
Das Problem trat durch meine Maßnahmen bis jetzt nicht mehr auf. Falls jmd. ein paar Anmerkungen zu dieser Problematik hätte, würde ich mich dennoch sehr freuen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
In der CPU Diagnose lässt sich sehen, dass die entsprechenden Baugruppen für ein paar ms nicht verfügbar und dann wieder vorhanden sind.
Ein Spannungsverlust lässt sich mehr oder weniger ausschließen, da ein Reboot der Baugruppen viel länger dauern würde und nicht so extrem kurz wäre.
Bei normale Einstellungen dauert ein Wiederanlauf nach Spannungsausfall bei mir etwa 6 Sekunden (Ethernet Autonegotiation, IP Adresse prüfen und verteilen, usw.). Als Gegenprobe könntest du das relativ einfach nachstellen.


Daher scheint es ein Problem im Profinet-Netzwerk selber zu sein.
Eine genauere Fehlerbeschreibung kann ich leider nirgendswo herauslesen.
Jedes PROFINET Device hat Verbindungsinfo sowie Zähler. Was ich schon mal hatte ist 100 Mbit Halb statt 100 Mbit Voll-Duplex, die Auto-Erkennung hat aus irgendein Grund versagt.

Die Zähler finde ich in TIA irgendwie nicht mehr :confused::evil:, Verbindungsinfo sieht in etwa so aus (extra ein altes Ethernet Device angehängt):
2014-12-23 09_30_55-C__TIA.png


Daher meine Fragen:
Ist meine Reaktion auf das Problem die richtige? Ist es normal, dass bei ca.20 Profinet-Teilnehmern solche Probleme mit dem Bus auftreten können?
Auch wenn es ersteinmal funktioniert, normal ist es nicht.


Ein Switch gibt ja in der Regeln Probleme auf einem Knoten/Busabschnitt nicht weiter auf die anderen Ports.
Das kommt drauf an. Wenn eine 'kritische' Teilstrecke überlastet ist, oder z.B. mit 10 MBit arbeitet, kann jeder Teilnehmer dahinter irgendwann ausfallen.
 
Bis jetzt ist das Problem immer noch nicht wieder aufgetaucht.
Die Busbelastung war anscheinend wircklich zu hoch. Bei einer Zykluszeit von 20ms macht es aber auch keinen Sinn in 1ms die Teilnehmer abzufragen. Von daher geht die geringe Reduzierung schon in Ordnung.
Die Auto-Erkennung der Teilnehmer hab ich gepürft, diese steht bei allen auf 100 Mbit Voll-Duplex.

Eine Frage bezüglich der Profinet-Topologie hab ich allerdings noch:
Die Anlage ist in der Baum-Struktur vernetzt. D.h. der "unterste" Teilnehmer hat den längsten Signal-Weg zum Kopf (Switch). Alle Geräte die eingesetzt werden haben mind. 2 Ports welche als Switch fungieren.
In einem Strang sind z.B. 10 Teilnehmer unterinander vernetzt. Macht es in der Profinet-Topolgie Sinn hier vom untersten Knotenpunkt wieder eine Verbindug zum Kopf zu machen?
Schließlich existieren für das Routing dann vom Switch aus 2 Wege zum Ziel. Kommt ein einfacher Siemens Scalance Profinet damit zurecht und kann er die kürzere Verbindung erkennen?
 
Nein, das wäre ein Ring, das muß ein Switch extra unterstützen ("Redundanz") und NUR 1 Weg wählen, weil die allermeisten Netzteilnehmer nicht damit klarkommen, wenn sie alle Telegramme zweimal bekommen.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wieso wäre das ein Ring? Da die einzelnen Geräte als eine Art "Switch" fungieren, haben wir ja nach wie vor den Typ BUS als Topologie. Demnach ist es der Topologie egal, ob ich nun mein Switch am Anfang und am Ende auflege. Ich spreche ja nur gewünschte Geräte an, und das einmal.

Andernfalls müssten die einzelnen Teilnehmer nicht mehr als Switch fungieren, d.h. ich müsste mein ganzes Netz bzw. deren Struktur umbauen um einen Ring zu erzielen.


Oder hab ich da was übersehen/ falsch gedacht?
 
Oder hab ich da was übersehen/ falsch gedacht?

Sehe ich ähnlich. Eine klassische Ring Topologie, wie zB zu Anfangszeiten des TCP/IP Netzwerkes wäre das nicht. Damals wurden beispielsweise die einzelnen Teilnehmer jeweils auf das im Ring gelegte Kabel einzeln draufgeklemmt. Wenn jedes Gerät ein Switch darstellt dann ergibt sich ja eigentlich kein Ring in dem Sinne mehr.

Ist es nicht so, dass ein Switch dahingehend funktioniert (und damit meine ich vor allem den Siemens-Switch als oberste Einheit des Netzes), dass er weiß an welchem Port sich welche IP-Adressen bzw genauer gesagt MAC-Adressen befinden und eingehende Pakete somit genau an den Port weiterleitet an dem er weiß dass das Zielgerät dahinter erreichbar ist. Auf mehrer Ports werden die Pakete nicht verteilt (im Gegensatz zum Hub, der einfach alles auf alle Ports ausgibt, ohne den Header der Pakete zu analysieren).
Ich denke, der "Ringschluss" könnte durchaus funktionieren und eine kleine bescheidene Performanceerhöhung bringen. Aber an der bestehenden Anlage will ich es natürlich auch nicht einfach so testen.
 
... eingehende Pakete somit genau an den Port weiterleitet an dem er weiß dass das Zielgerät dahinter erreichbar ist. Auf mehrer Ports werden die Pakete nicht verteilt (im Gegensatz zum Hub, der einfach alles auf alle Ports ausgibt, ohne den Header der Pakete zu analysieren).
Ich denke, der "Ringschluss" könnte durchaus funktionieren und eine kleine bescheidene Performanceerhöhung bringen. Aber an der bestehenden Anlage will ich es natürlich auch nicht einfach so testen.

Nein, das ist ein Ring, solange kein spezielles Protokoll wie Media Ring Protokoll (MRP) oder Spanning Tree (ist das bei Profinet überhaupt zulässig?) verwendet wird, welches redundante Leitungen (eigentlich Ports) deaktiviert.

Was etwas bringt ist die Tiefe zu reduzieren. Hier stellt sich die Frage, wie groß ist die Zykluszeit und was ist das aktuelle Anfrageintervall?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Eigentlich schon, ein Ring entsteht sobald man, von der Topologie her, einen Kreis zusammen bringt.
Es hängt von dann von eigenen Techniken (MRP, STP, RSTP, etc.) ob es überhaupt funktioniert.
Schließt man eine Reihe Switches im Kreis zusammen die das nicht unterstützen dann ist mit erheblich Performance-Einbußen oder Zusammenbruch zu rechnen.

wie zB zu Anfangszeiten des TCP/IP Netzwerkes wäre das nicht. Damals wurden beispielsweise die einzelnen Teilnehmer jeweils auf das im Ring gelegte Kabel einzeln draufgeklemmt.
Nicht mit Token-Ring verwechseln. :p

Ist es nicht so, dass ein Switch dahingehend funktioniert dass er weiß an welchem Port sich welche IP-Adressen bzw genauer gesagt MAC-Adressen befinden und eingehende Pakete somit genau an den Port weiterleitet an dem er weiß dass das Zielgerät dahinter erreichbar ist.
Insofern stimmt das schon, zu bestimmten Zeiten verhält sich aber auch ein Switch wie ein HUB (Broadcast-Pakete).
Wenn z.B. ein Switch für eine Dest-MAC noch keinen Eintrag in der MAC-Table hat, dann schickt er munter Broadcast-Pakete auf allen Ports raus. Die Broadcastpakete von den Switches und auch die der Teilnehmer selbst fließen munter im Kreis. Zumindest solange bis sie durch das TTL gekillt werden. Dafür gibt's einen schönen Begriff "Broadcast-Storm"

Es gibt soweit ich weiß dann auch noch andere Probleme auf div. Protokollebenen. So gut kenn ich's aber dann doch nicht. ;)
Für nen funktionierenden Ring muss mindestens einer im Kreis den Manager machen (der Rest muss dass MRP-Protokoll zumindest unterstützen).

wie Media Ring Protokoll (MRP) oder Spanning Tree (ist das bei Profinet überhaupt zulässig?
Ja, Profinet verwendet MRP. Lautwie Media Ring Protokoll (MRP) oder Spanning Tree (ist das bei Profinet überhaupt zulässig?[/QUOTE]"] dem Video hier brauch man anscheinend aber gar keinen separaten Redundanzmanager, weil es anscheinend die
Profnet-IO-Controller selber können. Bin mir aber nicht ganz sicher wie dass zu interpretieren ist.
[EDIT]Hab ne Liste entdeckt die zeigt welche Geräte, in welcher FW-Version, MRP unterstützen.[/EDIT]
 
Zuletzt bearbeitet:
MRP ist dann möglich wenn der Ring an der CPU geschlossen wird wenn ichs richtig im Kopf habe. Oder bei H-Systemen werden die Enden des Rings auf jeweils eine CPU gelegt.

Wie läuft die Anbindung ans SCADA von der SPS aus? Es gibt ja in der CPU noch die Reservierung der Kommunikationslast für die PROFINET-Kommunikation - wenn das SCADA im selben Netz bzw. über die selbe Schnittstelle an die Daten der CPU kommen will kann das auch dazu geführt haben. Wenn z.B. ein Bild mit besonders vielen Variablen abgefragt wird. Weiß aber nicht mehr wo die Einstellung Standardmäßig liegt, zu lange kein PROFINET mehr gemacht.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich denke, der "Ringschluss" könnte durchaus funktionieren und eine kleine bescheidene Performanceerhöhung bringen.

Schließt man eine Reihe Switches im Kreis zusammen die das nicht unterstützen dann ist mit erheblich Performance-Einbußen oder Zusammenbruch zu rechnen.

Zumindest solange bis sie durch das TTL gekillt werden. Dafür gibt's einen schönen Begriff "Broadcast-Storm"

Wenn der Ring mit der gleichen Geschwindigkeit steckt wie die restlichen Switchports, dann hast du innerhalb von Sekunden einen Totalausfall.
Unbekannte Broad- oder Multicasts werden an allen Ports ausgegeben und laufen endlos im Kreis > 100% Auslastung.
Die TTL hilft dabei wenig weil ein IP Parameter, dafür interessiert sich ein Switch im Regelfall nicht. Falls doch bleiben immer noch Frames ohne IP Header (die PN selbst mitbringt).
Selbst wenn der Ring sagen wir nur mit 10Mbit geschlossen ist (heute unwahrscheinlich) und der Rest auf 100Mbit läuft, wird das ausreichen um Großteil der PN Device zu überfordern.

Für einen MRP Ring müssen alle beteiligten Baugruppen MRP unterstüzten und die Ringports entsprechend eingestellt sein.
> Es reicht ein Manager im Ring. Das kann, muss aber nicht der IO Controller sein.

Die Umschaltungzeit bei MRP ist garantiert < 200ms
> Dabei muss die Ansprechüberwachungszeit der Device > 200ms sein, um ohne Störung weiterzumachen.

Bei STP ist die Umschaltzeit im (zweistelligen) Sekundenbereich.
Bei standard RSTP - soweit ich weiß - besten Falles < 2s, aber nicht fest.
> Beides "geht" natürlich auch - mit einem kurzzeitigen Ausfall dazwischen.

Überhaupt, stell die Zeiten/Retries auf das notwendige Minimum - die voreingestellten Werte sind m.M. zu 90% Unsinn.
Kleiner 10ms wird jeder größere Huster auf dem Netz zu einem Ausfall.
 
Wo kann man denn die Anzahl nicht gesendeter Pakete erhöhen?
Höre das zum Ersten mal und habe auch nicht gefunden.... :-(

Die hier beschriebene "Anzahl nicht gesendeter Pakete" bezeichnet man als "​akzeptierte Aktualisierungszyklen ohne IO-Daten​" und ergibt mit dem Sendetakt "Aktualisierungszeit" eine sogenannte Ansprechüberwachungszeit. Wenn nach Ablauf dieser Zeit der Controller kein gültiges Profinet RT Telegramm vom IO-Device erhält, so gilt das als Stationsausfall.
2019-01-17 07_09_37-C__Emco_5 TIA V15_Teststation_MSR_Teststation_MSR.jpg
In Abhängigkeit des zu steuernden Prozesses wird der Takt so langsam wie möglich gewählt (niemals so schnell wie möglich). Die Anzahl Zyklen ohne IO-Daten belassen wir im Normalfall auf 3.
Die Topologie eines Profinet Netzwerks muss entsprechend des Sendetakts so gewählt werden, dass die Linientiefe zum Sendetakt passt. Ebenfalls ist darauf zu achten dass nicht unnötiger TCP/IP-Traffic durch eine Linie gesendet wird (Stichwort Jitter & Discard). Siehe IBN Richtlinie für Profinet Seite 91 Tabelle 5-2.

Grüsse
 
Zurück
Oben