PROFIBUS Kommunikation TP177B und S7-410 nur bei CPU Stop

[cneukirchinger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,
ich habe ein Problem, bei dem ich langsam nicht mehr weiter weiss:

Bei der Erweiterung eines bestehenden PROFIBUS DP Strangs um mehrere Teilnehmer können zwei bestehende Panels (TP177B) keine Verbindung mehr zur S7-410 aufbauen. In der Ausgangskonfiguration konnten die Panels (WinCC flexible 2008) Daten aus der Steuerung (PCS 7 V8.0) lesen und schreiben. Beide Panels waren in der Hardwarekonfig nicht projektiert.



In der neuen Konfiguration können die Panels nur noch Daten aus der Steuerung lesen und schreiben, sobald diese in Stop gebracht wird. Sobald sie wieder in Run gebracht wird, bricht die Kommunikation bei den Panels zusammen. Alle anderen PROFIBUS Teilnehmer funktionieren tadelos.

Zusammen mit Siemens wurden bereits folgende Maßnahmen durchgeführt

• Anpassung PROFIBUS Parameter (Änderung Profi und manuelle Erhöhung der Zykluszeiten, projektierte Zykluszeit Bestand ca. 50ms, nach Erweiterung 82ms, Zykluszeiten bis 1000ms getestet)
• Verringerung der Profibus Geschwindigkeit von 1,5 Mbit/s auf bis zu 93,75 kbit/s
• Änderung der projektierten Zyklusbelastung der CPU (5 - 50%)
• Änderung der PROFIBUS Adressen beider Panels
• Projektierung der Panels im PCS7 Multiprojekt (als "Andere Station")
• DP-Repeater misst eine Zykluszeit von 20-30ms im Profibus
• Anpassung der Kommunikation im WinCC flexible Projekt (Einziger Master am Bus ja/nein, Zyklisches Übertragen der Busparameter ja/nein)

Leider führte das bisher nicht zur Lösung des Problems. Hat jemand auch schon mal eine solche Beobachtung gemacht oder noch einen Tipp für mich an welcher Stelle man noch etwas tun kann?

Viele Grüße und besten Dank,
Christian

 

[JesperMP]

Dass die Panels funktioniert mit den CPU in STOP aber nicht mit den CPU in RUN deutet an dass das Problem liegt bei den CPU.
Genau welchen CPU ist das ?
Was ist den Zykluszeit von den CPU ?

Ich denke nicht dass die Ursache ist dass der CPU keine freie Verbindungsressourcen hat. Ich wurde es aber trotzdem checken.
Eigentlich sollte 2 Panele kein Problem sein für die Verbindungsressourcen. Es sei denn, es gibt Verbindungen die nicht freigegeben werden.
Wenn das Problem auftaucht, auf den CPU online checken ob es freie Verbindungen gibt.

Was sind den Aktualisierungszeit für die Variabeln auf die Panels ? Wenn 100 ms, probier mal auf 500 ms oder 1000 ms zu vergrössern.
Gibt es vielleicht sehr viele Variabeln projektiert auf die Panels ?

Müssen die Panels auf den Profibus sein ?
CPU und Panels auf denselbe Profibus System bedeutet dass den Profibus von einfache Master-Slave ins Multi-Master System wird.
Das verringert den Buszykluszeit um ein Faktor 10 (!).
edit: Nein, da hat ich mir geirrt. Das passiert nur wenn man mehrere DP-Master/Slave Systeme in einen DP-Netz hat.
Ich wurde empfehlen entweder die Panels auf Ethernet oder ein separaten Profibus System zu verlegen.
Hast du den Möglichkeit dies zu testen ?

edit:
Genau welchen Bus-Parameter, u.A. Busprofil ist projektiert ?

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Eine Verringerung der Übertragungsgeschwindigkeit ist in den Fall vermutlich kontraproduktiv.
Wenn du das Busprofil auf "Benutzerdefiniert" umstellst, dann lassen sich in den Optionen die entsprechende Anzahl an S7-Teilnehmern und der Buslast einstellen. Dann werden die Busparameter entsprechend anders berechnet. Daraus resultiert eine höhere Ttr, denn nur in der Pausenzeit zwischen der zyklischen Kommunikation erhält ein DP-Master Klasse 2 (ein HMI) den Token.

Ich würde die gesamten Parameter wieder auf Urzustand zurückstellen. Dann das Busprofil auf Benutzerdefiniert umstellen und die entsprechende Anzahl an S7-Teilnehmern einstellen, und SPS damit laden. Auf den Panels darf in keinem Fall die Option "einziger Master am Bus" eingestellt sein. Dann mit jedem Panel einzel testen ob es am Bus funktioniert, dann zusammen.

 

[Blockmove]

Ich würde hier mal zurück auf Anfang.

• Busparameter auf Standard (nicht DP)
• 2 neue Projekte für die Panels mit nur einer Handvoll Variablen zum Testen
  Die Panels sollten integriert ins Projekt und dürfen nicht Master sein

Schauen ob's dann klappt.
Danach Variabeln und Bilder vom alten Panel-Projekt ins neue Projekt kopieren.
Wir hatten vor Jahren ein ähnliches Problem und da hat diese Vorgehensweise geholfen.

 

[cneukirchinger]

Genau welchen CPU ist das ?
Was ist den Zykluszeit von den CPU ?

Hier kommt eine 410-5H (6ES7 410-5HX08-0AB0) in der Firmware V8.0 zum Einsatz.
Die gemessene Zykluszeit beträgt 4ms (längste 80ms).
Der Profibus-Repeater hat eine Profibus Zykluszeit von 20-30ms gemessen.

Ich denke nicht dass die Ursache ist dass der CPU keine freie Verbindungsressourcen hat. Ich wurde es aber trotzdem checken.
Eigentlich sollte 2 Panele kein Problem sein für die Verbindungsressourcen. Es sei denn, es gibt Verbindungen die nicht freigegeben werden.
Wenn das Problem auftaucht, auf den CPU online checken ob es freie Verbindungen gibt.

Die Ressourcen sehen relativ frei aus. Die OP-Kommunikation berücksichtigt hier wohl beide redundante OS-Server. Im Büro habe ich ein Simulationssystem mit einer CPU und einem TP1900 Comfort aufgebaut, damit ich mit den Profibus Parametern spielen kann. Hier funktioniert die Kommunikation auch tadelos, wenn das Panel abgeschalten wird, dann verringert sich die Anzahl der belegten OP-Kommunikation um 1. Natürlich ist das Testsystem nicht wirklich aussagekräftig.

Was sind den Aktualisierungszeit für die Variabeln auf die Panels ? Wenn 100 ms, probier mal auf 500 ms oder 1000 ms zu vergrössern.
Gibt es vielleicht sehr viele Variabeln projektiert auf die Panels ?

Auf Panel 1 habe ich 35 und auf Panel 2 75 Variablen mit je einem Erfassungszyklus von 1000ms.

Müssen die Panels auf den Profibus sein ?
CPU und Panels auf denselbe Profibus System bedeutet dass den Profibus von einfache Master-Slave ins Multi-Master System wird.
Das verringert den Buszykluszeit um ein Faktor 10 (!).
edit: Nein, da hat ich mir geirrt. Das passiert nur wenn man mehrere DP-Master/Slave Systeme in einen DP-Netz hat.
Ich wurde empfehlen entweder die Panels auf Ethernet oder ein separaten Profibus System zu verlegen.
Hast du den Möglichkeit dies zu testen ?

Leider müssen die Panels auf dem Profibus sein, da ich den den Vor-Ort-Kästen keine andere Anschlussart zur Verfügung habe. Ein neues Kabel legen, ist momentan auch die schlechteste Lösung, da wir uns in einem Reinraum bewegen. Ethernet wäre wirklich schöner.

edit:
Genau welchen Bus-Parameter, u.A. Busprofil ist projektiert ?

Der PROFIBUS läuft mit 1,5 Mbit/s im Profil DP und hat eine Ttr von 87.2ms und Ttr typisch 22.6ms. Die typische Ttr deckt sich ja wohl mit der Messung des Diagnose Repeaters. In verschiedenen Testläufen habe ich das Profil auf Standard gestellt und mittels der Optionen die Anzahl der Netzteilnehmer verändert. Damit habe den den Bereich von Ttr 300ms bis 1500ms ausprobiert.

Vielen Dank für die Antwort!

 

[centipede]

Zuviel Werbung?
-> Hier kostenlos registrieren

Was micht etwas wundert ist, dass der Zustand der CPU eine Rolle spielt. Normalerweise arbeitet der Profibus Task unabhängig vom Zustand der CPU. Ob die 410 das auch so macht, kann ich nicht sagen, denke aber schon.
Am besten wäre hier mal eine Telegrammaufzeichnung am Bus, ob die Panel weiterhin sauber den Token bekommen und Daten austauschen.

 

[cneukirchinger]

Ich würde die gesamten Parameter wieder auf Urzustand zurückstellen. Dann das Busprofil auf Benutzerdefiniert umstellen und die entsprechende Anzahl an S7-Teilnehmern einstellen, und SPS damit laden. Auf den Panels darf in keinem Fall die Option "einziger Master am Bus" eingestellt sein. Dann mit jedem Panel einzel testen ob es am Bus funktioniert, dann zusammen.

Meinst du wirklich Benutzerdefiniert? Weil hier müsste man die alle Parameter (Tslot_Init, Max. Tsdr, ...) händisch eingestellt werden. Ich habe es auf Standard gestellt und konnte dann in den Optionen die Anzahl der DP-Master und DP-Slaves unabhängig von der Hardwarekonfig einstellen.

Auf den Panels war der Haken "einziger Master am Bus" immer schon aktiv. Ich höre und lese immer die unterschiedlichsten Meinungen was der Haken definitiv bewirkt. Soweit ich es verstanden habe gibt es Klasse 1 DP-Master (CPU) und Klasse 2 DP-Master (PG, OP) die sich gegenseitig nicht behindern sollten? Nur wenn ich ein PROFIBUS System, wie z.B. Panel + DP-Slaves (ohne CPU) habe, dann muss der Haken gesetzt sein. Nichts desto trotz führte das Setzen und Nicht-Setzen des Hakens bei beiden Panels bisher leider auch nicht zum Erfolg.

Vielen Dank für deine Antwort!

 

[cneukirchinger]

Ich würde hier mal zurück auf Anfang.

• Busparameter auf Standard (nicht DP)
• 2 neue Projekte für die Panels mit nur einer Handvoll Variablen zum Testen
  Die Panels sollten integriert ins Projekt und dürfen nicht Master sein

Die Integration der Panel-Projekte in das PCS 7-Multiprojekt habe ich auch ausprobiert. Leider steckt hier wieder der Teufel im Detail, weil auf der Kunden ES kein WinCC flexible 2008 installiert ist. Und ich die Panels dann aus meinem PG laden musste. Leider hat das aber auch nicht funktioniert.

Ich wollte hier mal die grundsätzliche Frage stellen, ob ich ein TP177 stromlos neustarten muss oder bloße Transfer ausreicht, um die geänderte Verbindungskonfiguration des Panels zu übernehmen? Die Änderung der Profibus Adresse wurde durch einen abgeschlossenen Transfer übernommen, damit kann ich annehmen, dass auch die anderen Einstellungen dann übernommen werden?

 

[centipede]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja übertragen reicht

 

[PN/DP]

- Das Profil "DP" ist falsch, wenn auch HMI/OP angeschlossen sind. "DP" ist für Netze mit nur "DP"-Diensten. Für Netze mit HMI/OP sollte das Profil "Standard" gewählt werden, in schwierigen Fällen "Benutzerdefiniert"
- "Einziger Master" darf nur aktiviert werden, wenn das HMI/OP tatsächlich der einzige aktive Teilnehmer am Bus ist. Wenn ein DP-Master vorhanden ist, dann ist ein HMI nie "einziger Master".
- "Zyklisches Verteilen der Busparameter" sollte aktiviert werden
- Wenn Busparameter geändert werden, dann müssen die neuen Busparameter in alle aktiven Teilnehmer geladen werden. Wenn mehrere HMI/OP vorhanden sind, dann bringt das Ändern/Laden nur eines HMI/OP nichts, wenn die anderen HMI/OP noch weiter mit den alten Busparametern arbeiten. Tip: testweise alle HMI/OP ausschalten oder vom Bus trennen und mit nur einem HMI/OP testen.

Harald

 

[cneukirchinger]

Was micht etwas wundert ist, dass der Zustand der CPU eine Rolle spielt. Normalerweise arbeitet der Profibus Task unabhängig vom Zustand der CPU. Ob die 410 das auch so macht, kann ich nicht sagen, denke aber schon.

Ich fände es auch interessant, was die CPU im Stopp mit dem PROFIBUS macht. In einem Service Request mit Siemens habe ich leider auch keine Antwort bekommen.

Am besten wäre hier mal eine Telegrammaufzeichnung am Bus, ob die Panel weiterhin sauber den Token bekommen und Daten austauschen.

Ich habe mit einem Indusol PB-INspektor NT den PROFIBUS untersucht, aber nur festgestellt, dass es bei den Panels und der CPU häufige Telegramm Wiederholungen gibt. Leider bekomme ich mit diesem Tool keine Infos, über den Inhalt der Telegramme.

 

[cneukirchinger]

Zuviel Werbung?
-> Hier kostenlos registrieren

- Das Profil "DP" ist falsch, wenn auch HMI/OP angeschlossen sind. "DP" ist für Netze mit nur "DP"-Diensten. Für Netze mit HMI/OP sollte das Profil "Standard" gewählt werden, in schwierigen Fällen "Benutzerdefiniert"
- "Einziger Master" darf nur aktiviert werden, wenn das HMI/OP tatsächlich der einzige aktive Teilnehmer am Bus ist. Wenn ein DP-Master vorhanden ist, dann ist ein HMI nie "einziger Master".
- "Zyklisches Verteilen der Busparameter" sollte aktiviert werden
- Wenn Busparameter geändert werden, dann müssen die neuen Busparameter in alle aktiven Teilnehmer geladen werden. Wenn mehrere HMI/OP vorhanden sind, dann bringt das Ändern/Laden nur eines HMI/OP nichts, wenn die anderen HMI/OP noch weiter mit den alten Busparametern arbeiten. Tip: testweise alle HMI/OP ausschalten oder vom Bus trennen und mit nur einem HMI/OP testen.

Harald

Vielen Dank, diesen Donnerstag kann ich an die Anlage wieder ran und werde erstmal nur mit einem Panel die Parameter ausprobieren und das andere abschalten.

 

[PN/DP]

Anhang anzeigen 46197

An dem OLM ist der LWL die Verbindung zur S7-410 und die beiden Bus-Stränge rechts und unten sind an dem RS485-Anschluß angeschlossen? Dann hat das Profibus-Segment hinter dem OLM zu viele Teilnehmer: 35 - es sind nur 31 Teilnehmer zulässig! Auch ohne die Erweiterung war die max. Anzahl Teilnehmer im Segment schon überschritten. Du brauchst einen weiteren RS485-Repeater (oder der vorhandene/neue Repeater muß versetzt werden).

Harald

 

[cneukirchinger]

An dem OLM ist der LWL die Verbindung zur S7-410 und die beiden Bus-Stränge rechts und unten sind an dem RS485-Anschluß angeschlossen? Dann hat das Profibus-Segment hinter dem OLM zu viele Teilnehmer: 35 - es sind nur 31 Teilnehmer zulässig! Auch ohne die Erweiterung war die max. Anzahl Teilnehmer im Segment schon überschritten. Du brauchst einen weiteren RS485-Repeater (oder der vorhandene/neue Repeater muß versetzt werden).
Harald

S7-410 und OLM sind über RS485 verbunden und der Lichtwellenleiter ist zwischen OLM (stellt in jedem Schrank eine Baugruppe dar) und den 4 DP-Slaves im unteren Bereich.

Ich hätte damit folgende Segmente identifiziert (wobei ich nicht sicher bin wie oft man den OLM und DP-Repeater mitzählt):

Segment 1: S7410 -> OLM -> 15 DP-Slaves -> TP177B -> 12 DP-Slaves (30 Teilnehmer)
Segment 2: OLM -> 4 DP-Slaves -> TP117B (6 Teilnehmer)
Segment 3: DP-Repeater -> 14 DP-Slaves (15 Teilnehmer)

Aus deiner Aussage schließe ich, dass der OLM kein neues Segment öffnet?

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Am RS485-Anschluß des OLM ist ein eigenes Segment. Egal wie viele Profibus-Kabel von dem einen Profibus-Stecker abgehen (1 oder 2) - es ist nur 1 Segment.
Dein OLM hat doch nur 1 RS485-Anschluß? Auf dem Anschluß steckt ein Profibus-Stecker mit einem Kabel zu "15 DP-Slaves ... TP177B ..." und einem Kabel zu "4 DP-Slaves ... TP117B"? Dann ist das nur 1 Segment mit 35 Teilnehmern.

PS: Vielleicht ist auch nur Dein Bild nicht ganz korrekt ... Wieviele OLM sind denn wirklich vorhanden und wo? Hast Du mal ein Bild, wo man alle OLM und Repeater sieht und wie die Profibusleitungen tatsächlich verlaufen?

Harald

 

[cneukirchinger]

Ich habe mich wirklich etwas unklar mit der Topologie ausgedrückt. Ich hoffe das Bild gibt das nun eindeutiger wieder.



Vielen Dank schon mal für die Antworten.

Ich habe nun auch ein Profibusmessgerät bekommen mit dem ich die Signalstärke und die Telegramme auslesen kann. Ich hoffe mir damit auch Informationen, was denn die CPU mit dem Profibus macht, wenn sie auf STOP ist.

 

[Fabpicard]

Leider müssen die Panels auf dem Profibus sein, da ich den den Vor-Ort-Kästen keine andere Anschlussart zur Verfügung habe. Ein neues Kabel legen, ist momentan auch die schlechteste Lösung, da wir uns in einem Reinraum bewegen. Ethernet wäre wirklich schöner.

Je nach Verkabelung ggf. eine Option:
TC EXTENDER 2001 ETH-2S - 2702409

MfG Fabsi

 

[centipede]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hast du schon mal die Busparameter aller aktiven Teilnehmer verglichen?
Die CPU und alle OPs sollten hier das selbe Profil mit den selben Parametern haben.
Da deine OPs nicht in das PCS7 Projekt integriert werden können, würde ich auch manuell die OPs in das Projekt einfügen.
Dazu das Profil auf Standard setzen, damit du was ändern kannst, Haken bei Netzkonfig berücksichtigen setzen und dann aktive Teilnehmer mit S7 Kommunikation um 2 erhöhen.
Danach die Busparameter als Muster für die OPs verwenden.
In flexible das Profil aller Ops auch auf Standard und bei dem Parameter "Anzahl der Master" auf 3 stellen.
Die Busparamter auf dem OP sollten dann eigentlich zusammenpassen.

 

[cneukirchinger]

Je nach Verkabelung ggf. eine Option:
TC EXTENDER 2001 ETH-2S - 2702409

MfG Fabsi

Gut zu wissen, dass es sowas gibt. Leider liegt hier zwischen den Vor-Ort-Kästen nur ein PROFIBUS Kabel und auf diesem Strang liegen noch andere Teilnehmer, so dass ich diesen nicht umfunktionieren kann. Danke schön!

 

[cneukirchinger]

Hast du schon mal die Busparameter aller aktiven Teilnehmer verglichen?
Die CPU und alle OPs sollten hier das selbe Profil mit den selben Parametern haben.
Da deine OPs nicht in das PCS7 Projekt integriert werden können, würde ich auch manuell die OPs in das Projekt einfügen.
Dazu das Profil auf Standard setzen, damit du was ändern kannst, Haken bei Netzkonfig berücksichtigen setzen und dann aktive Teilnehmer mit S7 Kommunikation um 2 erhöhen.
Danach die Busparameter als Muster für die OPs verwenden.
In flexible das Profil aller Ops auch auf Standard und bei dem Parameter "Anzahl der Master" auf 3 stellen.
Die Busparamter auf dem OP sollten dann eigentlich zusammenpassen.

Momentan sind die Panel Projekte in einem Step7-Projekt integriert. Wenn ich in dieser Hardwarekonfig die Busparameter (Standard + Anzahl Netzteilnehmer) einstelle, da muss ich in WinCC flexible ebenfalls die das Profil auf Standard stellen. Bei mir lokal werden wird das geänderte Bus Profil nicht übernommen.

Die Integration der WinCC flexible Projekte in das PCS 7 Projekt werde ich beim Kunden leider nicht durchführen können. Ich hoffe, dass es ausreicht, die Panels als "Andere Station" in NetPro einzufügen, damit die CPU diese in der Parameter Berechnung berücksichtigen kann.