TIA Profinet ausfall mit Sick Sicherheitssteuerung

[SPS_Stefan]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo liebe Gemeinde,

@ admin: hab kein passendes Thema gefunden wenn es eines geben sollte bitte verschieben.

ich habe ein Problem mit dem Profinet, kurz was verbaut ist:

1 x CPU 1515 2 PN
2 x IM 155-5 PN ST
1 x KTP900 100 F
1 x Panel PC
3 x Wiegezellen HBM
3 x Sick CPU mit Gateway und Baugruppen
24 x Frequenzumrichter der Firma Stöber

Auf die CPU und die IM Baugruppen kommen in Summe ca. 300 E/A´s

Problem:
Sobald die 3 Sick CPU s im Profinet eingebunden sind steigen diese mit einem Kommunikations Time Out aus und müssen neu gestartet werden.
Lege ich diese 3 CPU s in ein separates Profinet auf den zweiten PN der 1515 2 PN laufen diese Problemlos. (Nein ich kann es nicht so lassen )

Nach unendlichen versuchen seitens Sick (neu GSD Datei, neue Firmware etc.) Haben diese nun resigniert und behaupten ich habe einen zu hohen Traffic.
Das liegt nahe, sehe ich ein. Aber nehme ich meine 24 Frequenzumrichter vom Bus passiert es trotzdem. Ich habe schon jede einzelne Baugruppe aus und nacheinander wieder eingesteckt. Ein Muster ist leider keines zu erkennen. Sobald die Anzahl der Teilnehmer seigt (egal welche) passiert es. Aber nur bei den Sick alle anderen Teilnehmer laufen normal bei voller Teilnehmerzahl am Bus. Keinerlei Diagnoseeinträge.
Auch das erhöhen der Akzeptierten Aktualisierungszyklen ohne IO Daten auf über 2 Sekunden (was Irrsinn wäre bei einer Sicherheits CPU) bringt nichts.

Die Umrichter kommunizieren mit 72 Worten In/Out je.

Kann es wirklich wahr sein das, dass Profinet ausgelastet ist?
Oder hat jemand einen Tipp woher das kommen kann?

Vielen Dank

Grüße

 

[RogerSchw85]

Nein das ist bei weitem nicht ausgelastet.

Ich habe ähnliche Probleme mit den Flächenscanner von SICK bei einer Rockwell SPS. Von SICK sind sie freigegeben von Rockwell nicht. Dasselbe Gerät! Anscheinend hat SICK Probleme mit zu hohem Traffic und verliert danach die IP Adresse. Vielleicht ist es etwas ähnliches bei dir...

 

[xperia]

Zuviel Werbung?
-> Hier kostenlos registrieren

ev. die Aktualisierungszeit an den IO Devices raufstellen wenn möglich. Standardmäßig ist diese glaub ich auf automatisch.

 

[Lipperlandstern]

Ihr macht mir Angst. Ich muss diese Woche auch noch 3 SICK-Bauteile in einen relativ volles (mehr als 100 Teilnehmer) Profinet einbinden.... vielleicht verschiebe ich es auch auf nächstes Jahr

 

[SPS_Stefan]

Hey, merci für deine Antwort.

wie hast du das Problem bei dir gelöst?

 

[SPS_Stefan]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hey, merci für deine Antwort.

wie hast du das Problem bei dir gelöst?

 

[RogerSchw85]

Musste ich nicht. Das war die Evaluierungsphase und das Projekt wir erst nächsten Frühling umgesetzt. Ich hoffe bis dahin hat man die Probleme im Griff

 

[Spleanify]

Problem:
Sobald die 3 Sick CPU s im Profinet eingebunden sind steigen diese mit einem Kommunikations Time Out aus und müssen neu gestartet werden.
Lege ich diese 3 CPU s in ein separates Profinet auf den zweiten PN der 1515 2 PN laufen diese Problemlos. (Nein ich kann es nicht so lassen )

Das klingt für mich nach einem Topologieproblem:

- Wenn die Sick CPU's Profisafedaten empfangen/versenden (was ich annehme) so ist ist die maximale Anzahl Zyklen ohne IO-Daten 1. Die Akzeptierten Aktualisierungszyklen ohne IO Daten gelten nur für Standard Profinet RT Telegramme.
- Tauschst du grosse Mengen Profninet-Daten per Transferbereich aus?
- Stimmt die Linientiefe der Profinet-Devices in abhängigkeit zu der Aktualisierungsgeschwindigkeit?
- Wie sieht die Topologie aus? Stern, Ring, Bus, Baum oder reine Linie? und vor allem, wo innerhalb der Topologie sind die SICK-Cpus?
- Schiebst du TCP/IP-Traffic durch dasselbe Netzwerk die betroffene Ethernetlinie? Webcams zur visuellen Überwachung eines Prozesses z.B.?

 

[SPS_Stefan]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das klingt für mich nach einem Topologieproblem:

- Wenn die Sick CPU's Profisafedaten empfangen/versenden (was ich annehme) so ist ist die maximale Anzahl Zyklen ohne IO-Daten 1. Die Akzeptierten Aktualisierungszyklen ohne IO Daten gelten nur für Standard Profinet RT Telegramme.
- Tauschst du grosse Mengen Profninet-Daten per Transferbereich aus?
- Stimmt die Linientiefe der Profinet-Devices in abhängigkeit zu der Aktualisierungsgeschwindigkeit?
- Wie sieht die Topologie aus? Stern, Ring, Bus, Baum oder reine Linie? und vor allem, wo innerhalb der Topologie sind die SICK-Cpus?
- Schiebst du TCP/IP-Traffic durch dasselbe Netzwerk die betroffene Ethernetlinie? Webcams zur visuellen Überwachung eines Prozesses z.B.?

Hallo,

Die Sick haben ein Profinet Gateway über das keine Sicheren Daten gesendet werden. Ich erhalte darüber nur Informationen über die Zustände der angeschlossenen Schalter, Not-Halt und ob die Schutzkreise i.O. sind um in der SPS Fehlermeldungen oder Status Informationen zu generieren.

I Device und Transferbereich nutze ich nicht. Die Kommunikation zu den Teilnehmern erfolgt Zyklisch über DPRD_DAT und DPWR_DAT im geschlossenen Profinet

Die Linientiefe: Wir haben 5 Schaltschränke, im ersten die CPU dann jeder Schrank einen Switch 16 Fach in Line verbunden zum nächsten. Von jedem Switch Sternförmig zu den Teilnehmern je Schrank auch Sick. Laut indu-sol.com sind bei Store and Forward Switchen eine Linientiefe von 14 mit 2 ms angegeben. Ich bin deutlich unter 14 und habe die Aktualisierungszeit auf Automatisch gestellt.
Die Siemens IM haben 2 ms die Sick automatisch 64 ms.
Jedoch bin ich hier absolut kein Fachmann und lasse mich gerne eines besseren belehren.


TCP/IP haben wir nur einen Panel PC mit Visu und einen Fernwartungsrouter von MB Connect sonst keinen Traffic was das angeht.

Vielen Dank für deine Antwort

 

[Blockmove]

Die Linientiefe: Wir haben 5 Schaltschränke, im ersten die CPU dann jeder Schrank einen Switch 16 Fach in Line verbunden zum nächsten. Von jedem Switch Sternförmig zu den Teilnehmern je Schrank auch Sick.

Die Switche alle in einer Linie ist nicht so ganz optimal. Wenn es die Leitungslänge zulässt, könntest du hier mal versuchsweise mehr Richtung Stern verkabeln.
Aber nicht vergessen die Topologie anzupassen

 

[SPS_Stefan]

Die Switche alle in einer Linie ist nicht so ganz optimal. Wenn es die Leitungslänge zulässt, könntest du hier mal versuchsweise mehr Richtung Stern verkabeln.
Aber nicht vergessen die Topologie anzupassen

Hey,

ich habe mir deine Aussage zur Topologie zu herzen genommen.
Alle Teilnehmer sind nun Sternförmig. Der am weitesten entfernte Switch hat eine Kabellänge von 45 Meter.

• CPU an Switch 1.
• Von dort alle Switche angefahren
• Von den einzelnen Switchen jeden Teilnehmer angefahren (manche Teilnehmer haben integrierte Switche, diese nutze ich nicht mehr sondern fahre wie gesagt auf den Hauptswitch jedes Schaltschrankes.
• Jeden Teilnehmer den ich verbunden habe, habe ich gepingt und wieder ausgesteckt um einen IP Adressen Konflikt zu vermeiden.

Das Problem besteht weiterhin aber nur bei Sick. Keiner meiner anderen Teilnehmer meldet ein Problem.

Verbinde ich die 3 Sick mit Ihren integrierten Switchen untereinander so, dass nur die letzte Sick mit meinem Profinet verbunden ist fallen nicht mehr alle drei Sick sporadisch aus sondern nur noch die mit meinem Netzwerk verbunden ist.

Es ist egal was ich ausstecke solange die Sick nicht im eigenen Netzt hängt habe ich sporadische ausfälle.

Das Thema EMV möchte ich nahezu ausschließen. Ich habe die drei größten Motorenkabel von der Schirmschiene genommen und mehrmals gestartet. Es spielte einiges verrückt und viel aus nicht die Sick.

 

[The Blue]

Zuviel Werbung?
-> Hier kostenlos registrieren

Eine Skizze der Topologie wäre echt hilfreich!
Ist die Topologie auch in der SPS hinterlegt?
Welcher Switch wurde verwendet?
Wird IRT eingesetzt?
Wie ist Sendetakt, Aktualisierungszeit und Watchdog eingestellt?
Ist das Netzwerk ein 100% ProfiNet?

 

[Rauchegger]

Das ist ein Problem, welches nur mit den neuen CPU´s auftritt, ich bin mir nicht sicher aber ich denke die haben da was am PN Standart geändert, so das die Teilnehmer zugemüllt werden mit Daten/Abfragen usw. und die CPU sofort beleidigt ist wenn sich ein Teilnehmer nicht sofort zu einer Antwort bereit erklärt....
Ich konnte es jetzt mehrfach Reproduzieren mit den CPU 1516-3 bzw Softsps 1507S und mit 10 Stk OCP von Wenglor (PoE) und 2 Wenglor Switch ebenfalls PoE... nach 30min wird der letzte Sensor in der Topologie (auch Phisikalisch der letzte) ausgeknipst, nach weiteren 30min. der 5P Switch... und immer wieder das selbe...
Mit Win AC RTX 2010 läuft alles stabil, auch mit doppelt so vielen Teilnehmern! in dieser Kompination habe ich es seit 6 Jahren bei fünf Anlagen im Einsatz... nie auch nur das kleinste Problem ......


Mitlerweile habe ich von einigen Wenglor Mitarbeiternerfahren das Wenglor mit Siemens wegen diesem Problem in Kontakt steht.....

Mir wurde von Big S gesagt ich sollte nur mehr "managt Switch" verwenden!!

 

[SPS_Stefan]

Eine Skizze der Topologie wäre echt hilfreich!
Ist die Topologie auch in der SPS hinterlegt?
Welcher Switch wurde verwendet?
Wird IRT eingesetzt?
Wie ist Sendetakt, Aktualisierungszeit und Watchdog eingestellt?
Ist das Netzwerk ein 100% ProfiNet?

Skizze klappt grade nicht kann ich nachreichen. 4 Schaltschränke jeder ein Switch. Alle Switche sind in Stern zum ersten Schaltschrank. In den Schränken selber die Umrichter alle in Stern auf den Switch.

Die Topologie ist nicht hinterlegt da ich keine Managed Switche habe.

Phönix Contact SFN 16TX

IRT nein

Sendetakt CPU IO Kommunikation 1 ms. Kann hier auch nichte einstellen
Aktualisierungszeit und Watchdog: WO finde ich die?

Nein nicht 100 % es hängt noch ein Panel PC TCP/IP drin.

 

[urlaub]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wir hatten hier eine Maschine mit ca. 60 Teilnehmern und alle mit mehreren Phoenix SFN 8TX verbunden. Es gab immer wieder sporadisch Teilnehmerausfälle.
Nachdem einige Switche durch Siemens XB208 ausgetauscht wurden läuft es.

 

[Blockmove]

Also ich verwende nur noch Managed Switche und Topologie.
Bei der Fehlersuche und Diagnose sind die Mehrkosten schnell wieder drin.

 

[The Blue]

Sobald die 3 Sick CPU s im Profinet eingebunden sind steigen diese mit einem Kommunikations Time Out aus und müssen neu gestartet werden.
Lege ich diese 3 CPU s in ein separates Profinet auf den zweiten PN der 1515 2 PN laufen diese Problemlos.

Grüße

SPS_Stefan, sind die 3 Sick CPUs PN-Controller oder Devices?


Also im TIA Portal kann man den Sendetakt zwar ändern
aber bei mir gibt es dann Fehler beim Kompilieren
sobald ich von 1ms Sendetakt abweiche !?

Der Watchdog heißt bei Siemens im TIA-Portal Ansprechüberwachung
und ist das ein Vielfaches der Aktualisierungszeit

zum Thema unmanaget Switches: Wenn man sich nicht gerade in der Gebäudetechnik befindet,
sollte man min. die Konformitätsklasse-B umsetzen - sprich managed Switches
Einfach mal in die Planungsrichtlinie der PI schauen
https://de.profibus.com/downloads/profinet-installation-guidelines/

 

[The Blue]

Zuviel Werbung?
-> Hier kostenlos registrieren

Also ich verwende nur noch Managed Switche und Topologie.
Bei der Fehlersuche und Diagnose sind die Mehrkosten schnell wieder drin.

Mit einem TAP und WireShark lässt ich auch einiges herausfinden.
Auch ohne managed Switches. Wobei ich diese auf jeden Fall bevorzuge.

 

[Blockmove]

Mit einem TAP und WireShark lässt ich auch einiges herausfinden.
Auch ohne managed Switches. Wobei ich diese auf jeden Fall bevorzuge.

Klar, aber es sind halt so Kleinigkeiten, wie Kabelcheck, Logging oder Mirrorport.
Bei heterogenen Netzten zudem noch QoS.

 

[Spleanify]

Also ich verwende nur noch Managed Switche und Topologie.
Bei der Fehlersuche und Diagnose sind die Mehrkosten schnell wieder drin.

Ich möchte mich der Meinung von Blockmove voll und ganz anschliessen und damit wir wieder beim Thema sind: Wireshark kann hier durchaus ein probates Mittel sein dem Fehler auf die Schliche zu kommen. Portmirror + Wireshark und mal den zeitlichen Versatz der Telegramme ansehen, bzw. ob überhaupt alle durchkommen. Bei einem neuen System muss meiner Meinung nach 100% der Telegramme konsistent beim Empfänger ankommen, wenn nicht darf eine Anlage erst gar nicht raus (--> IBN-Richtlinie für PN-RT).

Zum Thema Switches: Scalance 200er Serie ist sicherlich eine gute Wahl für den Aufbau solcher Netzwerke. Wir verwenden nur noch XC208/216/224. Zur not halt noch die 100er Serie wenns wirklich günstig sein muss, aber Finger weg von der 0er Serie. Die Phoenix Switche hab ich noch nie verwendet, nur deren MGuard Router.