Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 15

Thema: CPU Stop - PROFINET IO: Stationswiederkehr

  1. #1
    Registriert seit
    08.10.2007
    Beiträge
    125
    Danke
    13
    Erhielt 0 Danke für 0 Beiträge

    Ausrufezeichen


    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?
    Zitieren Zitieren CPU Stop - PROFINET IO: Stationswiederkehr  

  2. #2
    Registriert seit
    11.09.2007
    Ort
    Suedwestpfalz
    Beiträge
    917
    Danke
    81
    Erhielt 209 Danke für 192 Beiträge

    Standard

    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.
    Das Grauen lauert in der Zwischenablage !!

  3. Folgender Benutzer sagt Danke zu dtsclipper für den nützlichen Beitrag:

    Fluffi (19.12.2014)

  4. #3
    Registriert seit
    03.04.2008
    Beiträge
    6.206
    Danke
    237
    Erhielt 818 Danke für 692 Beiträge

    Standard

    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
    "Any fool can write code that a computer can understand.
    Good programmers write code that humans can understand."
    --Martin Fowler

  5. #4
    Fluffi ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    08.10.2007
    Beiträge
    125
    Danke
    13
    Erhielt 0 Danke für 0 Beiträge

    Standard

    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.
    Geändert von Fluffi (19.12.2014 um 20:34 Uhr)

  6. #5
    Fluffi ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    08.10.2007
    Beiträge
    125
    Danke
    13
    Erhielt 0 Danke für 0 Beiträge

    Standard

    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.

  7. #6
    Registriert seit
    28.03.2012
    Ort
    Hessen
    Beiträge
    117
    Danke
    4
    Erhielt 20 Danke für 18 Beiträge

    Standard

    Zitat Zitat von Fluffi Beitrag anzeigen
    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.


    Zitat Zitat von Fluffi Beitrag anzeigen
    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 , Verbindungsinfo sieht in etwa so aus (extra ein altes Ethernet Device angehängt):
    2014-12-23 09_30_55-C__TIA.png


    Zitat Zitat von Fluffi Beitrag anzeigen
    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.


    Zitat Zitat von Fluffi Beitrag anzeigen
    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.
    Kaum macht man es richtig, schon funktioniert es.

  8. #7
    Fluffi ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    08.10.2007
    Beiträge
    125
    Danke
    13
    Erhielt 0 Danke für 0 Beiträge

    Standard

    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?

  9. #8
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.316
    Danke
    932
    Erhielt 3.331 Danke für 2.689 Beiträge

    Standard

    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
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  10. #9
    Registriert seit
    30.07.2014
    Beiträge
    291
    Danke
    67
    Erhielt 34 Danke für 20 Beiträge

    Standard

    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?
    Freundliche Grüße aus München, der Stadt mit Herz


    There are 2#10 kinds of people, those who do the work & those who take the credit.

  11. #10
    Fluffi ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    08.10.2007
    Beiträge
    125
    Danke
    13
    Erhielt 0 Danke für 0 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Münchnerjunge Beitrag anzeigen

    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.

Ähnliche Themen

  1. TIA PROFINET Teilnehmererweiterung ohne CPU Stop
    Von SanjaDO im Forum Simatic
    Antworten: 10
    Letzter Beitrag: 30.10.2015, 10:32
  2. Antworten: 1
    Letzter Beitrag: 28.10.2014, 13:20
  3. S5 CPU 103 - stop
    Von Hr.Nehrving im Forum Simatic
    Antworten: 5
    Letzter Beitrag: 14.12.2011, 06:55
  4. CPU geht in Stop
    Von JoJo17 im Forum Simatic
    Antworten: 1
    Letzter Beitrag: 26.05.2008, 11:06
  5. Antworten: 4
    Letzter Beitrag: 28.03.2008, 20:09

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •