Keine Verbindung mit OP170B (zuviel Busteilnehmer?)

Wastel

Level-1
Beiträge
77
Reaktionspunkte
2
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe seit heute ein Problem mit einem OP170B.
Dieses Panel wird seit ca. 2 Jahren problemlos an einem Profibus-Strang mit 20 Busteilnehmer (ET200 & Festo CPV10) betrieben.
Der Profibusstrang ist über einen CP443-5 an einer CPU417-4 angeschlossen.
Wie gesagt seit 2 Jahren ohne Probleme.

Jetzt wurde dieser Profibus-Strang um 3 ET200 & 3 Festo CPV10 erweitert.
(Jetzt also 26 Slaves & 1 OP170B am Bus)
Seitdem die neuen Profibus-Teilnehmer am Bus angeschlossen sind,
kann sich das OP170B nicht mehr mit der Steuerung verbinden.
Wenn ich jetzt mind. 5 beliebige Busteilnehmer ausschalte verbindet sich das Panel wieder sofort mit der CPU.
Kommt ein Busteilnehmer hinzu, wird die Verbindung sofort wieder abgebaut.
Ein Adresskonflikt liegt nicht vor! (mind. 10x überprüft ;))
In der Spezialdiagnose des CP´s kann ich sogar die Adresse des Panels sehen!

Woran könnte das liegen? Zuviel Kommunikation (CPU->Slaves), sodass das Panel keine Zeit mehr findet Daten mit der CPU auszutauschen?
Oder gibt es eine Beschränkung wieviel Slaves man in Verbindung mit einem Panel an einer CPU betrieben kann?

Grüße und einen guten Rutsch.... :D
 
Hallo Wastel,

auch wenn die maximale Anzahl von Teilnehmern pro Segment noch nicht erreicht ist, rate ich doch mal einen Repeater - so vorhanden - einzuschleifen.
Da du ja nur ein paar binäre E/A zugefügt hast, ist die Erhöhung der Buszykluszeit in deinen Fall wohl nicht das Problem.
Hast du die Mindestleitungsleitungslänge zwischen zwei Profibusteilnnehmern beachtet. Das waren wohl 50cm, wenn ich mich
recht entsinne.

Gruß

Frank
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hast du die Mindestleitungsleitungslänge zwischen zwei Profibusteilnnehmern beachtet. Das waren wohl 50cm, wenn ich mich
recht entsinne.
Von einer Mindestleitungslänge habe ich noch nie was gehört und darum habe ich mal gesucht:

http://support.automation.siemens.com/WW/view/de/28922114

ANTWORT:
Es gibt keine definierten Mindestlängen bei elektrischen Profibusleitungen. Diese Eigenschaft ist unabhängig von der verwendeten Übertragungsgeschwindigkeit.

Hatte aber auch noch nie das Problem. ;)
 
Hallo,
ich würde sagen, das hier die B&B-Dienste (Bedienen & Beobachten) gegenüber den DP-Diensten (dezentrale Perepherie) "einfach" in den Hintergrund geschoben werden. Das ist m.E. nicht wirklich ein Verdrahtungsthema sondern eher ein Auslastungsthema.

Es ist also so, wie du vermutest :
Zuviel Kommunikation (CPU->Slaves), sodass das Panel keine Zeit mehr findet Daten mit der CPU auszutauschen
ggf. kannst du das ändern, wenn du die Aktualisierungsrate der OP-Variablen hochsetzt.

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Schau mal in den Eigenschaften des Profibus nach dem Busprofil.
Wenn es auf DP steht, dann es stell es auf Standard. Mit den Einstellungen des Bus-Profils legst du das Verhältnis DP-Kommunikation zu anderen Kommunikationsdiensten (HMI,FDL,PG,...) fest.

Gruß
Dieter
 
Ich tippe mal auf Timing. Die Master haben eine bestimmte Zeitscheibe um die Slaves abzufragen. Danach wird der Token weitergegeben. Wenn jetzt ein Master den Token erhält und die TTR (Target Token Rotating Time) abgelaufen ist, dann muss er ihn sofort weitergeben ohne etwas getan zu haben.
Deshalb einfach mal des Timing des Busses entsprechend großzügiger einstellen, d.h. mehrere Master und Slaves berücksichtigen. Bei Siemens kann man in der Busprofileinstellung schön herumspielen und sieht die Auswirkungen.
 
Deshalb einfach mal des Timing des Busses entsprechend großzügiger einstellen, d.h. mehrere Master und Slaves berücksichtigen. Bei Siemens kann man in der Busprofileinstellung schön herumspielen und sieht die Auswirkungen.

Dabei aber Neustart der Slaves (Spannung aus/ein) nicht vergessen :)

Gruß
Dieter
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Dabei aber Neustart der Slaves (Spannung aus/ein) nicht vergessen :)

Gruß
Dieter

Ist das wirklich notwendig? Ich dachte durch die Konfigurationsänderung geht der Master vom Bus und wenn er wiederkommt initialisiert er die Slaves mit den entsprechenden Parametern.
 
Ist das wirklich notwendig? Ich dachte durch die Konfigurationsänderung geht der Master vom Bus und wenn er wiederkommt initialisiert er die Slaves mit den entsprechenden Parametern.

Im Zusammenspiel mit OPs am Bus, hab ich mir das angewöhnt. Meist übersetz ich das OP-Projekt auch neu und übertrage es ins OP.

Gruß
Dieter
 
Erstmal vielen Dank für Eure Tipps.

Zitat von IBFS:
auch wenn die maximale Anzahl von Teilnehmern pro Segment noch nicht erreicht ist, rate ich doch mal einen Repeater - so vorhanden - einzuschleifen.
Mit einem Repeater habe ich schon getestet.
Den habe ich direkt an der CPU mit in den Bus mit eingeschliffen.
Am Verhalten hat sich jedoch nichts geändert.


Ich denke mal mein Problem geht eher in die Richtung wie von Rainer beschrieben:
Zitat von Rainer Hönle:
Ich tippe mal auf Timing. Die Master haben eine bestimmte Zeitscheibe um die Slaves abzufragen. Danach wird der Token weitergegeben. Wenn jetzt ein Master den Token erhält und die TTR (Target Token Rotating Time) abgelaufen ist, dann muss er ihn sofort weitergeben ohne etwas getan zu haben.
Das Panel ist übrigens nicht im Step7 Projekt integriert.

@Rainer: Mit welchen Parametern kann ich denn das Timing des Busses beeinflussen?
In den "Eigenschaften der Profibus-Schnittstelle" kann man unter "Optionen" bei "Netzteilnehmer" die "Anzahl DP-Master" eingeben.
Ich denke dort müsste ich die DP-Master eintragen, die nicht in der HW-Konfig aufgeführt sind.
Wie z.B. mein Panel, dieses ist ja ein separates WinCCFlex-Projekt und nicht in Step7 integriert.
Wenn ich dieses mit berücksichtige, müßte dies ja einen direkten Einfluss auf die Berechnung der Buszykluszeit haben!?

Ich werd mal sehen dass ich am Montag noch ein wenig testen kann.
Erstmal vielen Dank und einen "guten Rutsch"
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Erstmal vielen Dank für Eure Tipps.

Mit einem Repeater habe ich schon getestet.
Den habe ich direkt an der CPU mit in den Bus mit eingeschliffen.
Am Verhalten hat sich jedoch nichts geändert.


Ich denke mal mein Problem geht eher in die Richtung wie von Rainer beschrieben:
Das Panel ist übrigens nicht im Step7 Projekt integriert.

@Rainer: Mit welchen Parametern kann ich denn das Timing des Busses beeinflussen?
In den "Eigenschaften der Profibus-Schnittstelle" kann man unter "Optionen" bei "Netzteilnehmer" die "Anzahl DP-Master" eingeben.
Ich denke dort müsste ich die DP-Master eintragen, die nicht in der HW-Konfig aufgeführt sind.
Wie z.B. mein Panel, dieses ist ja ein separates WinCCFlex-Projekt und nicht in Step7 integriert.
Wenn ich dieses mit berücksichtige, müßte dies ja einen direkten Einfluss auf die Berechnung der Buszykluszeit haben!?

Ich werd mal sehen dass ich am Montag noch ein wenig testen kann.
Erstmal vielen Dank und einen "guten Rutsch"

Hallo,

zum Ändern des Timings stell in der Hardwarekonfig das Busprofil von DP auf Benutzerdefiniert um, dann kannst du die Busparameter ändern.

Gruß Woldo
 
... Wie z.B. mein Panel, dieses ist ja ein separates WinCCFlex-Projekt und nicht in Step7 integriert.
Wenn ich dieses mit berücksichtige, müßte dies ja einen direkten Einfluss auf die Berechnung der Buszykluszeit haben!?

Hallo,
dann hat der Rainer mit seiner Timing-Theorie sogar noch mehr als Recht. Ich hätte allerdings vorausgesetzt, dass das OP in das Projekt mit integriert ist und somit in der NetPro-Konfiguration eingetragen ist und dann auch automatisch korrekt bei der Kommunikation mit berücksichtigt wird. Vielleicht solltest du das vor Allem anderen erstmal tun und dann sehen wir weiter ... :rolleyes:

Gruß
Larry
 
Das Panel ist übrigens nicht im Step7 Projekt integriert.

@Rainer: Mit welchen Parametern kann ich denn das Timing des Busses beeinflussen?
In den "Eigenschaften der Profibus-Schnittstelle" kann man unter "Optionen" bei "Netzteilnehmer" die "Anzahl DP-Master" eingeben.
Ich denke dort müsste ich die DP-Master eintragen, die nicht in der HW-Konfig aufgeführt sind.
Wie z.B. mein Panel, dieses ist ja ein separates WinCCFlex-Projekt und nicht in Step7 integriert.
Wenn ich dieses mit berücksichtige, müßte dies ja einen direkten Einfluss auf die Berechnung der Buszykluszeit haben!?
Richtig, unter PROFIBUS > Eigenschaften > Netzeinstellungen das Profil des Profibus auf "Standard" ändern und dann bei Optionen > Netzteilnehmer die Anzahl zu berücksichtigender DP-Master erhöhen.
In diesen Einstell-Dialogen gibt es auch sehr informative Hilfe-Buttons ...
Busprofil "Standard"
Gegenüber dem Profil "DP" bietet das Profil "Standard" zusätzlich die Möglichkeit, Teilnehmer eines anderen STEP7-Projektes oder Teilnehmer, die nicht mit STEP 7 projektiert wurden, bei der Berechnung der Busparameter zu berücksichtigen. Die Busparameter werden dann nach einem einfachen, nicht optimierten Algorithmus berechnet.

Siehe auch:
Zusätzliche PROFIBUS-Teilnehmer berücksichtigen


Ist das wirklich notwendig? Ich dachte durch die Konfigurationsänderung geht der Master vom Bus und wenn er wiederkommt initialisiert er die Slaves mit den entsprechenden Parametern.
Im Zusammenspiel mit OPs am Bus, hab ich mir das angewöhnt. Meist übersetz ich das OP-Projekt auch neu und übertrage es ins OP.
Ich bin auch so "übervorsichtig", daß ich nach einer Busparameter-Änderung alle aktiven Teilnehmer neu lade.
Zusätzlich aktiviere ich das "Zyklische Verteilen der Busparameter".

Harald
 
Von einer Mindestleitungslänge habe ich noch nie was gehört und darum habe ich mal gesucht:

http://support.automation.siemens.com/WW/view/de/28922114

Hatte aber auch noch nie das Problem. ;)

Ich kenne das auch mit den 50cm als Mindestlänge zwischen 2 Busteilnehmern.

Ich würde auf jeden Fall auch das HMI-Projekt neu übersetzen, bzw. die Station neu übertragen. Das wird eigentlich im Netpro als Warnung eingeblendet und hat mit dem veränderten Bustiming zu tun, wenn am Bus geändert wird.
 
Ach ja:
Im separaten OP170B-Projekt muß das Netzprofil auch auf "Standard" geändert werden und die Anzahl der Master (aktive Stationen) eingegeben werden (falls das da nicht schon richtig drin steht), weil es ja nicht integriert ist.
Das "Einziger Master am Bus" muß beim OP170B natürlich deaktiviert sein.

Allerdings kann man bei Standalone-Projekten in WinCCflex (und ProTool) keine genaueren Busparameter angeben.
Eventuell beachtet das OP170B auch die vom DP-Master zyklisch versendeten Busparameter-Telegramme (eventuell im Profil "Universal"?) und man muß im Step7-Projekt/NetPro diese Option nur aktivieren?

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Eventuell beachtet das OP170B auch die vom DP-Master zyklisch versendeten Busparameter-Telegramme (eventuell im Profil "Universal"?) und man muß im Step7-Projekt/NetPro diese Option nur aktivieren?

Harald

Laut Infos auf einer Profibusschulung bei uns im Hause, beachten die Siemens Panels die Busparameter welche verschickt werden. Aber auch nur die, da dies nicht im DP Standart definiert ist!
 
Hier ist doch der Hund begraben.
Man muss das OP manuell ein die
Kommunikationsresourcen eintragen.

Gruß

Frank

Diese Einstellung hat nur den Effekt, dass die SPS eine Verbindungsresource für das OP reserviert. Damit soll verhindert werden, dass alle Verbindungen belegt sind und das OP nicht mehr auf die SPS zugreifen kann.
Dies hat nichts mit der Anzahl der Master (welcher Art auch immer) am Bus zu tun.
 
So...

ich bin nun endlich mal zum Ausprobieren gekommen.
Leider wird auf der Anlage wieder fleißig produziert,
so dass ich leider nur wenig Zeit zum Testen hatte.

Also,
ich habe nun alle Varianten durch.
Beim CP443-5 habe verschiede Bus-Profiltypen ausprobiert:
DP, Standart & Benutzerdefiniert
Bei diesen habe ich die Anzahl Master bei den Netzteilnehmers erhöht.
Ich habe es mit der Einstellung 1, 2 & 3 Master probiert.
Den Anteil S7-Kommunikation hatte ich zwischendurch auf "Hoch"
Beim Panel habe ich auch alle Bus-Profiltypen probiert.
Abwechselnd mit der Einstellung "Einziger Master" (jeweils aktiviert und deaktiviert)
Alles leider ohne Erfolg!

Da leider wieder mal Produktionsdruck herrscht und ich in absehbarar Zeit nicht wieder an der Steuerung "rumspielen" kann,
wollte ich in den Busparametern (Profil Benutzerdefiniert) nichts ändern!

Ich habe das Panel jetzt auf ein Bussegment (anderer CP) mit nur 6 Busteilnehmern gelegt (mittels Trennung eines Repeaters).
Dort funktioniert das Panel ohne Probleme, leider muss jetzt nur ein neues Kabel zum Panel gezogen werden.
Aber mit dem Repeater im Bus sollte das ja im laufenden Betrieb gehen.

Tja, ich bin ja erstmal beruhigt, dass das Panel wieder geht,
ist aber trotzdem nicht unschön, dass ich den "entscheidenden Haken" nicht gefunden habe... :?

Aber trotzdem möchte ich allen für die doch sehr hilfreichen Beiträge danken.

Gruß Wastel
 
Zurück
Oben