Profibus: Siemens TP´s verlieren Kommunikation

[maddin]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo miteinander,

ich hatte heute ein seltsames Problem. Wir haben eine große Anlage mit einer Zentralsteuerung S7-416 F/2. Am Profibus hängen ca.10 Siemens TP´s 170, versch. Profibuskopplern und dezentrale Busstationen sowie ein PC, welcher die Produktionsdaten erfasst, insgesamt ca. 40 Teilnehmer.
Es passierte heute, daß bei ca. 5 von den Touchpanels die Kommunikation zur Steuerung verlorenging. Wurde eine Schaltfläche betätigt, erscheinte die Meldung" Variable konnte nicht mit Steuerung ausgetauscht werden".
Auch die aktuellen Istwerte wurden nicht dargestellt.
Im Diagnosepuffer wurde jedoch nichts aufgezeichnet, lediglich kurze Ausfälle von anderen Stationen (Millisekundenbereich). Die TP´s habe ich durch Ein-/und Ausstecken der Versorgungsspannung wieder initialisiert, selbst danach war im Diagnosepuffer nichts eingetragen.
Werden solche "siemensintegrierte" Teilnehmer anders behandelt als andere Slaves?
Welche Diagnosemöglichkeiten habe ich ? Ich möchte herausfinden, ob eine schlechte Verbindung besteht oder ein einzelner Slave das Netzwerk übermäßig belastet. (Ist dies beim Profibus überhaupt möglich? Kenne mich mit den Protokollen nicht aus)

Über Antworten und Tipps würde ich mich sehr freuen

Gruß Maddin

 

[Ralle]

Es gibt in der Hardwarekonfig unter Zyklus/Taktmerker den Eintrag Zyklusbelastung durch Kommunikation. Diesen solltest du auf jeden Fall erhöhen, ist er zu niedrig eingestellt, kommt es zu solchen Ausfällen. Habt ihr die TP in der Hardwarekonfig mit eingetragen? An Hand der eingetragenen Geräte werden die Busparameter von der Software berechnet. Aktive Slaves müssen ja nicht zwingend im Bus eingetragen sein, ist aber besonders in diesem Falle sinnvoll.

SIehe auch hier: http://www.sps-forum.de/showthread.php?t=11743&highlight=Kommunikationslast

 

[maddin]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Ralle, vielen Dank für deine Antwort.

Die Zyklusbelastung durch kommunikation ist bei 30% angegeben, falls du das meinst. Die Anlage läuft nun seit 4 Jahren und hatte noch nie solche Ausfälle.
Die TP´s tauchen in der HW-Konfig nicht auf, nur im Net-pro.
Meinst du wirklich, daß es nur an diesem Wert liegen kann und nicht an einer schadhaften Verbindung/Leitung ?
Gruß maddin

 

[Ralle]

Na ja, sicher kann das auch eine defekte Leitung oder ein anderer Einfluß sein, der die Bus stört. Wie schnell ist der denn? Wenn die TP mit im Profibus integriert sind sollte man zumindest in einem Testprojekt mal die TP mit in den Profibus einbinden und sich dann die Profibusparameter aufschreiben. Diese dann zumindest mal bei der Hardwarkonfig so eingeben (Das kann man manuell machen oder die Software rechnet das automatisch aus und stellt es ein). Bei so vielen TP würde ich die Kommunikationslast auch mal testweise höher nehmen, wir hatten hier schon Berichte, wo bei 6 Panels 50% eingestellt wurden, wenn ich mich recht erinnere. Außerdem sollten aktive Teilnehmer keine Adressen haben, die direkt nebeneinander liegen. Bei Mastern bin ich mit sicher, daß es so war, bei den aktiven Slave (TP sind das) nicht ganz, aber schaden kann es auf keinen Fall. Weiß nicht, ob das eine gute Idee ist, so eine Menge TP mit an den Profibus mit EA zu hängen, ich hätte die eher an den MPI-Bus genommen, natürlich nur, wenn das vernünftig machbar ist (Länge der Kabel ist bei MPI recht kurz) oder eine extra CP eingesetzt.

 

[maddin]

Hallo,

@Ralle: Vielen Dank für die Antwort (hörst du auch mal auf zu arbeiten ? .-)

Ich hab den Hersteller der Anlage auf das Problem angesprochen. In der Hardware möchte ich nach Möglichkeit nichts ändern, da in der CPU auch fehlersichere Hardware projektiert ist (2 verschiedene Profibusnetze, 1.Kreis normaler Profibus 1,5 MB/s, 2.Kreis fehlersicherer Profibus 12 MB/s.)
Da fehlts warscheinlich dann an ein paar Optionspaketen.

Aber doch die Frage: Warum tauchen die TP´s nicht im Diagnosepuffer auf, wenn ich die Versorgungsspannung abziehe (kein OB 85 oder OB 86 Aufruf). Und warum werden TP´s als aktive Slaves behandelt ?

Gruß maddin

 

[marlob]

Zuviel Werbung?
-> Hier kostenlos registrieren

Weiß nicht, ob das eine gute Idee ist, so eine Menge TP mit an den Profibus mit EA zu hängen, ich hätte die eher an den MPI-Bus genommen, natürlich nur, wenn das vernünftig machbar ist (Länge der Kabel ist bei MPI recht kurz) oder eine extra CP eingesetzt.

MPI kann unter bestimmten Vorraussetzungen bis zu 1000 m.
Siehe dazu diesen Beitrag von mir. Da hier 400er SPSen eingesetzt sind, sollte die Vorraussetzung erfüllt sein.

 

[maddin]

Guten Morgen,

@Ralle: hörst du auch mal auf zu arbeiten ?? .-)

Ich habe den Hersteller der Anlage auf das Problem aufmerksam gemacht. In der Hardware möchte ich nichts ändern, da auch fehlersichere Hardware eingesetzt wird. So wie ich Siemens kenne, fehlen mir dazu mit Sicherheit mehrere Optionspakete. Es sind 2 Profibus-Netzwerke konfiguriert, 1. Kreis normaler Profibus mit 1.5 MB/s, der 2. Kreis ist der fehlersichere Profibus mit 12Mb/s.
Warum tauchen die TP´s nicht im Diagnosepuffer auf, wenn ich die Versorgungsspannung abziehe (kein OB85 o. OB86 Aufruf) ?? Komisch !
Und warum sind TP´s aktive Slaves ?

Gruß Maddin

 

[maddin]

Nanu, jetzt steht meine Antwort doch drin. Hab zuerst gedacht, sie wurde nicht übernommen.....

sorry deswegen..

Gruß maddin

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Aber doch die Frage: Warum tauchen die TP´s nicht im Diagnosepuffer auf, wenn ich die Versorgungsspannung abziehe (kein OB 85 oder OB 86 Aufruf). Und warum werden TP´s als aktive Slaves behandelt ?

Gruß maddin

Also, ich habs gerade mal in der Hardwarekonfig ausprobiert, wenn du ein TP in ProTool mit der SPS verbindest und das dann abspeicherst, ändern sich automatisch die Busdaten in der Hardwarekonfig der SPS. Das bedeutet m.M., daß die TP nicht direkt mit in die Hardwarekonfig müssen (wenn man es da auch noch einträgt ändert sich nichts mehr an den Busparametern). Hängen die TP eingentlich an einer CP? OP85/86 könnte evtl. damit zusammenhängen. Für CP muß man extra Diagnosebausteine haben (zumindest für den CP342-5 im 300-er System). Wie das mit der 400-er und der 2. Profibusschnittstelle oder einer CP ist, weiß ich nicht.
Ich überwache auch noch im OB82 den Profibus, tut sich da auch nichts?

Eins ist klar, wenn die Anlage schon 4 Wochen problemlos lief, muß sich eigentlich etwas verändert haben. (Neue Anlagen, Maschinen, etc. im Umfeld) Wurde in der Nähe etwas umgebaut? Ein Diagnoserepeater würde sich da wohl ganz gut eignen, allerdings habe ich damit noch keine Erfahrung. Wenn das Netz mit der Länge evtl. an der Grenze ist oder Biegeradien der Leitungen zu eng sind (Die Elektriker verstecken zu lange Leitungen gerne im Kabelkanal und falten die dann schön zusammen :twisted, kann es bei kleinen Veränderungen losgehen.

 

[maddin]

Hallo,

nein, es ist keine CP im Busnetz vorhanden. Vom OB 82 ist im Diagnosepuffer nix zu sehen,bei einem Aufruf müßte der ja auch registriert werden.

Ich hab gerade auch versucht in der Hardwarekonfig die TP´s auch mit aufzunehmen. Komischerweise tauchen im Katalog keinerlei TP´s auf, die man einfügen könnte. Nur im Net-Pro sind sie aufgelistet.

Naja, egal. Das mit dem Diagnoserepeater habe ich mir auch schon überlegt, aber da wir noch mehr Anlagen mit Profibus haben, werde ich mir nach einem transportablen Profibus Tester Ausschau halten, den ich an allen Anlagen einsetzen kann.

Gruß Maddin

 

[Jo]

@maddin,
wenn in deinen TP's keine Profibus-Direkttasten projektiert sind, sind die TP's auch nicht in der HW-Konfig zu sehen. Es macht dann auch keinen Sinn diese in der HW-Konfig zu projektieren. DP-Tastenmodule findest du übrigens unter "bereits projektierte Stationen".
Die TP's unterhalten sich mit der CPU über die OP-Kommunikation.
Meine Vermutung ist eine Störung des Profibuses z.Bsp. durch eine längere Stichleitung zum PG.

mfG. Jo

 

[Bitverbieger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich glaube auch das sich hier in der Installation etwas verändert hat.
Bei 1,5MBit ist schon auf exakte Installation und Anschlüsse zu achten.
Ich würde, wenn es machbar ist, mal die Busgeschwindigkeit auf
500/187,5 KBit herunterstellen und dann schauen was passiert.
Damit ist zwar die Ursache nicht beseitigt, aber man weis in welche Richtung man suchen muss.

 

[maddin]

Hallo zusammen,

es gibt Neuigkeiten bezüglich des Problems.

Wir hatten vor kurzem einen Programmierer des Anlagenherstellers im Hause (wegen einer anderen Anlage). Den habe ich mit 2 Kaffee bestochen und um seinen Rat gebeten.
Wir haben zusammen über die Hardware drübergeschaut. Er meinte, daß er das Problem des öfteren schon hatte. Ursache seien fehlende Repeater zwischen den Slaves. Die Repeater seien zwar definiert nach der Länge der Busleitung und Anzahl der Slaves. Er meinte jedoch, es sei ein ungeschriebenes Gesetz (was Siemens auch inofiziell bekannt ist), daß man jedesmal nach 16 Slaves (oder waren es 18 ?) einen Repeater einsetzen sollte, unabhängig von der Leitungslänge. Er meinte, daß die Dämpfung (durch die steigende Zahl der Schnittstellen der Slaves+Busstecker) zu hoch werden würde.

Habt ihr das gewußt ?? Was meint Ihr dazu ?

Bei uns hängen zwischen 2 Repeatern 34 Slaves am Bus.

Gruß maddin

 

[vladi]

DP Störungen

Hi,
evtl. das http://www.sps-forum.de/showthread.php?t=17551 mal probieren..

Die Ursachen von solchen Aussetzer sind schwer zu finden. DP Baudrate
reduzieren bzw. Repeater hinzu bewirkt oft Wunder.

34 Slaves zwischen 2 Repeater..Wie genau verbunden.. da war was mit max 32 Slaves pro Segment.

Gruss: V.