-> Hier kostenlos registrieren
Hallo Hans-Ludwig, danke für deine Antwort!
Es kommt nur während der Bewegung zu Ausfällen, zumindest fällt es dann am ehesten auf.
Profinet: Überwachung des Verbindungspartners
- Ersteller Svensson
- Erstellt am
-> Hier kostenlos registrieren
Es kommt nur während der Bewegung zu Ausfällen, zumindest fällt es dann am ehesten auf.
-> Hier kostenlos registrieren
Danke @TSM so einen Baustein suche ich, allerdings steht er bei meiner CPU (IM151-8 F-CPU) im TIA (V16 Upd6) nicht zur Verfügung..
Zuletzt bearbeitet:
Ja der ist offentsichtlich nur bei 1500er CPUs vorhanden.
Aber du kannst aber bestimmt auch den Baustein "RDSYSST" benutzen.
Ich selber habe ihn zwar noch nicht verwendet aber nach dem was in der Hilfe steht müsste das gehen.
Das ist der gleiche baustein wie Larry Laffer in #5 geschrieben hat.
Einfach mal in der Suche SFC51 eingeben, da kommen einige Ergebnisse.
Aber du kannst aber bestimmt auch den Baustein "RDSYSST" benutzen.
Ich selber habe ihn zwar noch nicht verwendet aber nach dem was in der Hilfe steht müsste das gehen.
Das ist der gleiche baustein wie Larry Laffer in #5 geschrieben hat.
Einfach mal in der Suche SFC51 eingeben, da kommen einige Ergebnisse.
- Beiträge
- 22.182
- Reaktionspunkte
- 7.370
Der Baustein steht für 1200ér und 1500ér zur Verfügung.
Indu-Sol
Level-1
- Beiträge
- 66
- Reaktionspunkte
- 28
-> Hier kostenlos registrieren
Hallo Svensson,
vielen Dank für dein Feedback.
Es scheint ein recht großes Funksystem zu sein. Wenn man bei Siemens recherchiert, dann sind meistens ca. 50 WLAN Clients für einen Access Point möglich, wenn iPCF genutzt wird.
Deine Konfigurationen sehen gut aus, obwohl das Bild aus #19 keine Werte enthält. Hier sollten deine beschriebenen 256 ms auftauchen, vielleicht hattest du aber auch die CPU 317F-2 PN/DP ausgewählt und nicht die IM151-8 F-CPU.
Um der Ursache oder dem Verhalten auf die Schliche zu kommen, empfehle ich dir immer auch zusätzlich zur SPS-Diagnose eine Netzwerk-/PROFINET-Analyse vorzunehmen. Es ist wichtig auch unscheinbarere Fehler (fehlende, defekte oder zu späte Telegramme) aufzudecken zur weiteren Fehlereingrenzung. Dafür brauchst du im ersten Schritt nur Wireshark, um den Traffic der CPU 317F-2 PN/DP aufzuzeichnen und auszuwerten.... und ein bisschen Fachwissen und Zeit. Sollte dein Fehler häufig eintreten, dann kannst du damit starten.
Gezielter und effektiver geht es natürlich mit Analyse-Tools, die automatisch und permanent aufzeichnen und auswerten. Du kennst vielleicht den PROFINET-INspektor. Der ist sehr detailreich und findet schnell eindeutige Auffälligkeiten in der Netzwerkkommunikation. Dann weiß man, wo man weiter ansetzen muss.
Viele Grüße
Frank Lehmann
vielen Dank für dein Feedback.
Es scheint ein recht großes Funksystem zu sein. Wenn man bei Siemens recherchiert, dann sind meistens ca. 50 WLAN Clients für einen Access Point möglich, wenn iPCF genutzt wird.
Deine Konfigurationen sehen gut aus, obwohl das Bild aus #19 keine Werte enthält. Hier sollten deine beschriebenen 256 ms auftauchen, vielleicht hattest du aber auch die CPU 317F-2 PN/DP ausgewählt und nicht die IM151-8 F-CPU.
Um der Ursache oder dem Verhalten auf die Schliche zu kommen, empfehle ich dir immer auch zusätzlich zur SPS-Diagnose eine Netzwerk-/PROFINET-Analyse vorzunehmen. Es ist wichtig auch unscheinbarere Fehler (fehlende, defekte oder zu späte Telegramme) aufzudecken zur weiteren Fehlereingrenzung. Dafür brauchst du im ersten Schritt nur Wireshark, um den Traffic der CPU 317F-2 PN/DP aufzuzeichnen und auszuwerten.... und ein bisschen Fachwissen und Zeit. Sollte dein Fehler häufig eintreten, dann kannst du damit starten.
Gezielter und effektiver geht es natürlich mit Analyse-Tools, die automatisch und permanent aufzeichnen und auswerten. Du kennst vielleicht den PROFINET-INspektor. Der ist sehr detailreich und findet schnell eindeutige Auffälligkeiten in der Netzwerkkommunikation. Dann weiß man, wo man weiter ansetzen muss.
Viele Grüße
Frank Lehmann
Pipboy
Level-2
- Beiträge
- 232
- Reaktionspunkte
- 55
55 Clients an einem AP und die Büchsen schaffen es nicht mehr in einer knappen Sekunde ein Frame loszuwerden.
Der gesamte Traffic wird eine einzige "Auffälligkeit" sein.
Habe es jetzt mal in der Simulation laufen lassen. Leider sieht es so aus als ob meine CPU die Funktionalität nicht unterstützt.
Oder habe ich etwas grundlegendes falsch gemacht?
Anhänge
-> Hier kostenlos registrieren
Da könntest du Recht haben. Deswegen will ich im ersten Schritt die Verbindung zur Hauptsteuerung überwachen..
Wie gesagt ich haben den Baustein selber noch nicht verwendet aber ich denke du verwendest die falsche SZL_ID.
Schau mal hier:
https://www.sps-forum.de/threads/profinet-diagnose-mit-im151-8-cpu-unter-tia-v16.101941/#post-769398
In der Suche SFC51 oder RDSYSST eingeben hilft ungemein
Schau mal hier:
https://www.sps-forum.de/threads/profinet-diagnose-mit-im151-8-cpu-unter-tia-v16.101941/#post-769398
In der Suche SFC51 oder RDSYSST eingeben hilft ungemein
- Beiträge
- 9.804
- Reaktionspunkte
- 2.830
-> Hier kostenlos registrieren
Zum Thema WLAN-Planung und Auslegung gibt's bei Siemens extra Kurse. 55 Devices an einem AP im 5 GHz Band ist sehr ambitioniert.
Intern werden pro Device 2 ms Übertragungszeit reserviert. Mal 55 bedeutet das 110 ms Token-Umlaufzeit für alle (so sie alle einen Slot bekommen)
Die AP-Umlaufzeit muss somit auf 128 ms eingestellt werden. Die PN-Aktualisierungszeit kann 128 ms sein. Als PN-Überwachung wir Faktor 6 im Kurs gelehrt (also 768 ms). Für Safety nochmal Faktor 2 (also 1536 ms).
Mir kommt die Zahl 55 sehr hoch vor für einen AP. Kann es sein dass die Montagewagen sich ständig gegenseitig raus kicken? Auf welcher Fläche ist das aufgebaut? Verwendet ihr Leckwelle?
Gerne auch PN, komme aus der gleichen Industrie.
Intern werden pro Device 2 ms Übertragungszeit reserviert. Mal 55 bedeutet das 110 ms Token-Umlaufzeit für alle (so sie alle einen Slot bekommen)
Die AP-Umlaufzeit muss somit auf 128 ms eingestellt werden. Die PN-Aktualisierungszeit kann 128 ms sein. Als PN-Überwachung wir Faktor 6 im Kurs gelehrt (also 768 ms). Für Safety nochmal Faktor 2 (also 1536 ms).
Mir kommt die Zahl 55 sehr hoch vor für einen AP. Kann es sein dass die Montagewagen sich ständig gegenseitig raus kicken? Auf welcher Fläche ist das aufgebaut? Verwendet ihr Leckwelle?
Gerne auch PN, komme aus der gleichen Industrie.
Bzgl. Diagnose:
Ein ganz einfacher Mechanismus wäre ein klassisches High-Bit. Wenn die CPU einen Ausfall detektiert werden alle Eingänge 0.
Das bedeutet ein freies Bit am Montagewagen auf High-Setzen in der Schnittstelle und an der Zentralsteuerung auf = 0 Abfragen.
Diese Signale lassen sich dann ebenso einfach ins Meldesystem einbinden und mit Begleitwerten versehen.
Ein ganz einfacher Mechanismus wäre ein klassisches High-Bit. Wenn die CPU einen Ausfall detektiert werden alle Eingänge 0.
Das bedeutet ein freies Bit am Montagewagen auf High-Setzen in der Schnittstelle und an der Zentralsteuerung auf = 0 Abfragen.
Diese Signale lassen sich dann ebenso einfach ins Meldesystem einbinden und mit Begleitwerten versehen.
Vilen Dank für deine Nachricht! Ich werde deinen Input prüfen und bald Rückmeldung geben.
Da mein System auf 256ms läuft (hat man im Zuge der Fehleranalyse erhöht), sollte dann die Timeout-Safteyüberwachung auf 3072ms stehen, was es nicht tut. Mein AP steht sogar auf 512ms..
zu deinen Fragen:
Ob die Wägen sich gegenseitig rauskicken, kann ich nicht 100% sicher sagen, da es auch einen "PowerSafeMode" gibt und sie dann offline gehen - Auszuschließen ist das aber nicht.
Wir verwenden einen Leckwellenleiter von Siemens. Ich habe mit unserer IT und Gebäudetechnik eine Spektralanalyse machen lassen, die Ergebnisse waren ok. Ich kann zu 99% das WLAN als Ursache ausschliessen, auch die ErrorLogs vom AP sehen gut aus.
-> Hier kostenlos registrieren
Danke für den pragmatischen Ansatz
