Profibus Busfehler

[daMichael]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen!
Ich bin noch relativ am Anfang in meiner SPS-Karriere und habe nun hier folgendes Problem mit einer unserer Anlagen:
Wenn wir die Anlage über das Wochenende ausschalten (Hauptschalter raus), bekommen wir beim Anlauf immer einen Busfehler. Bei der CPU (416DP) leuchtet dann BUSF auf. Manchmal geht die CPU auf STOP, manchmal gibt es auch einen "Weihnachtsbaum", also alles leuchtet oder blinkt. Manchmal läuft die CPU auch nicht an, RUN blinkt dann die ganze Zeit (über Stunden). Irgendwann kann man die CPU dann wieder per Warmstart starten, und die Anlage läuft.
An einem Teil der Anlage haben wir vier Teilnehmer über einen Repeater angeschlossen. Hier ist es so, dass wir an einem der Enden den Abschlusswiderstand auf "OFF" stellen müssen, da sonst ein wieder ein Busfehler auftritt. Hier ist es egal, welcher der beiden Endwiderstände auf "OFF" steht.
Wir haben diese Woche eine der Teilleitungen ersetzt, dann war dieser Fehler weg, und es konnten beide Widerstände terminiert werden.
Am nächsten Tag trat der Fehler jedoch wieder auf.
Wir haben diverse Baugruppen und Stecker getauscht, jedoch lässt sich der Fehler bisher nicht beheben. Auch der Repeater in diesem Teil wurde testweise getauscht.
Insgesamt sind drei der Repeater verbaut.

Hat jemand eine Idee, woran das ganze liegen könnte?

Vielen Dank schonmal!

Gruß
Michael

 

[Hans-Ludwig]

Hallo daMichael,
das hört sich erst mal seltsam an. Ich drücke das mal anders aus, um es besser zu verstehen. Du baust einen Busfehler ein, in dem Du den Terminator ausschaltest und der Bus läuft hoch. Das heiß für mich, dass noch weitere Fehler drin sein müssen. Als erstes versuche ich mal die physikalischen Grundlagen zu überprüfen. Im zweiten Schritt dann die Hochlaufphase.
Busabschluß an jedem Segment Anfang und Ende auf ein. Also dort wo sich nur noch ein Kabel befindet. Dabei muss der Stecker richtig angeschlossen sein. Nur am Eingang wirkt der Busabschluß. Das könnte eine der Ursachen sein, manchmal ist das Kabel im Stecker am Ausgang angeschlossen. Vielleicht kannst Du Bilder machen und diese hier rein stellen, damit wir den Punkt abhaken können.
Repeater: Ich gehe mal von einem Siemens Repeater aus. Ist er am Ende so ist der Eingang links. Das zweite Segment wäre unten auch links anzuschließen. Sitzt der Repeater in der Mitte, so könnte oben und unten auch der rechte Anschluss belegt sein.
Wenn ich von Dir ein o.k. bekomme gehen wir in die nächste Runde.

Viel Erfolg Hans-Ludwig Göhringer

 

[rlw]

Zuviel Werbung?
-> Hier kostenlos registrieren

Einfache Regeln sind: wenn nur ein Kabel in der Stecker geht muss das Kabel in den oberen Eingang bzw in den Eingang wo der
Pfeil nach "rein" zeigt.
Immer wenn nur ein Kabel reingeht muss muss der Abschlusswiderstand auf ON stehen.

Nach meinen 20 Jahren Bus-Erfahrung kann ich sagen, dass wir hartnäckige Fehler nur mit einem Busanalyzer beseitigen.
Wir benutzen den Profitrace von Procentec.
Die Fehler liegen zu 90% in der Verkabelung und in den Steckern, defekte Slaves sind selten.

Erst nach 2009 wurden z.B. die Schiebeschalter mit Goldkontakten ausgestattet.

Ich habe mal bei einer Anlage 70 Stecker getauscht. Die Mikroskopaufnahmen der Kontrakte zeigten einen grauenhaftes
Bild, abwohl die Anlage in einem Reinraum steht.

 

[JesperMP]

Nach meinen 20 Jahren Bus-Erfahrung kann ich sagen, dass wir hartnäckige Fehler nur mit einem Busanalyzer beseitigen.
Wir benutzen den Profitrace von Procentec.

+1.
Hatte auch ein Fehler den wir ohne die Profitrace nie lokalisiert hätten.
Eventuell kann man die Profitrace mieten.

Erst nach 2009 wurden z.B. die Schiebeschalter mit Goldkontakten ausgestattet.

Ich habe mal bei einer Anlage 70 Stecker getauscht. Die Mikroskopaufnahmen der Kontrakte zeigten einen grauenhaftes
Bild, abwohl die Anlage in einem Reinraum steht.

OMG !
Das erklärt einiges.

 

[rlw]

+1.
Hatte auch ein Fehler den wir ohne die Profitrace nie lokalisiert hätten.
Eventuell kann man die Profitrace mieten.


OMG !
Das erklärt einiges.

Mieten wird nicht viel bringen. Es gehört schon sehr viel Erfahrung dazu die Telegramme und die Buspegel auszuwerten.
Manchmal müssen die Timings geändert werden, wenn die Slaves in die Jahre gekommen sind.
Oft hilft es schon einige Parameter zu ändern, z.B Retry_limit auf 5, dann sieht man welcher Slave wie oft
angesprochen wird bevor die CPU in stop geht.

Anbei eine Tabelle wie ich das bei Procentec gelernt habe.

Bei schwierigen Fälle würde ich jemand von Procentec dazuholen, oder mich.

Softing kann's auch.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn wir die Anlage über das Wochenende ausschalten (Hauptschalter raus)

Braucht die Anlage wirklich sooo viel Ruhestrom, daß sich das Ausschalten gegenüber dem Risiko des nicht wieder Anlaufens/teurem Anlagenstillstands lohnt? Reicht nicht auch einfach Notaus aktivieren?
Die meisten unserer SPS werden nie ausgeschaltet. Bei denen mit Daten-Verarbeitung haben wir sogar USV installiert um Stromausfälle bis 20 Minuten zu überbrücken. Einige Schaltschränke sind auch in feuchten Räumen mit 8°C Raumtemperatur, da benötigen die Schaltschränke ständig im Inneren etwas Wärmeleistung gegen Betauung/Kondenswasser und die Folgeschäden.
Der gefährlichste Moment im Leben von Elektronikkomponenten ist das Strom-Einschalten. Man muß teure Anlagen nicht unnötig oft diesem Risiko "Strom einschalten" aussetzen.

Manchmal geht die CPU auf STOP, manchmal gibt es auch einen "Weihnachtsbaum", also alles leuchtet oder blinkt.

STOP-Ursachen kann man im Diagnosepuffer der CPU nachlesen. Da fehlt wohl irgendeiner der üblichen OB.
"Weihnachtsbaum" kann auch dazu führen, daß sich die CPU nie wieder erholt/rücksetzen läßt!

Manchmal läuft die CPU auch nicht an, RUN blinkt dann die ganze Zeit (über Stunden).

Schau mal in den OB100, da ist vermutlich eine Schleife programmiert, die auf irgendwas wartet was nicht kommt. Prüfe: Muß das wirklich sein??

An einem Teil der Anlage haben wir vier Teilnehmer über einen Repeater angeschlossen. Hier ist es so, dass wir an einem der Enden den Abschlusswiderstand auf "OFF" stellen müssen, da sonst ein wieder ein Busfehler auftritt. Hier ist es egal, welcher der beiden Endwiderstände auf "OFF" steht.

Für die Abschlußwiderstände gibt es Regeln. Vielleicht sind auch zu viele Abschlußwiderstände eingeschaltet (Teilnehmer mit einfachen Abschluß-Einschaltern anstatt -Umschaltern)? Mehr als 2 Profibuskabel auf einem Anschlußpunkt (also Sternstruktur!)? Profibuskabel auch auf der PG-Buchse der Repeater?
siehe Systemhandbuch PROFIBUS Netzhandbuch

Wir haben diverse Baugruppen und Stecker getauscht, jedoch lässt sich der Fehler bisher nicht beheben.

Wir haben die Erfahrung, daß bei sich häufenden Profibus-Fehlern in > 10 Jahre alten Anlagen konsequentes Austauschen ALLER Profibus-Stecker zuverlässiger hilft als wochenlanges 'rumdocktern.

Harald

 

[rlw]

Wir haben die Erfahrung, daß bei sich häufenden Profibus-Fehlern in > 10 Jahre alten Anlagen konsequentes Austauschen ALLER Profibus-Stecker zuverlässiger hilft als wochenlanges 'rumdocktern.

Harald

Kann ich bestätigen, vor allem wenn die Stecker älter als 12 Jahre sind.

Als diverse Hersteller damals Profibusstecker produziert haben, war anscheinend keiner dabei der Ahnung von Übergangswiderständen und Kontaktmaterial hatte .
Ich hab sie alle erlebt und habe über 200 Stecker eingesammelt die alle das gleich Problem haben.

Ich gehe an keinen Bus mehr ohne Analyzer. Der Glaube, "wenn alle LED grün sind", muss alles richtig sein ist falsch.

 

[Gerhard Bäurle]

... Der Glaube, "wenn alle LED grün sind", muss alles richtig sein ist falsch.

Das wiederhole ich seite 10 Jahren immer wieder, wie z. B. hier:

https://digital.industrielle-automation.net/industrielle-automation-4-2015/56663135/27

Aber manche Digital Natives kennen halt nur zwei Zustände "geht" und "geht nicht".

 

[Dekuika]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kann ich bestätigen, vor allem wenn die Stecker älter als 12 Jahre sind.

Als diverse Hersteller damals Profibusstecker produziert haben, war anscheinend keiner dabei der Ahnung von Übergangswiderständen und Kontaktmaterial hatte .
Ich hab sie alle erlebt und habe über 200 Stecker eingesammelt die alle das gleich Problem haben.

Ich gehe an keinen Bus mehr ohne Analyzer. Der Glaube, "wenn alle LED grün sind", muss alles richtig sein ist falsch.

Wir haben sporadisch Busausfälle bei einer Kübelbahn, die aber teilweise über Funk läuft. Bisher dachte ich, das Wlan der LKW's, die darunter entladen, sei das Problem, aber da die Anlage von 2002 ist, werde ich die Busstecker erneuern. Der Leitrechner (Windows NT 4.0) ist auch aus der Zeit und wird, wie Harald schon erwähnt hat, niemals ausgeschaltet. Die Fehler, die dann auftreten, kennen wir zur genüge.

 

[JesperMP]

Mieten wird nicht viel bringen.

Warum nicht ? Auch eine kurze Verwendung von die Profitrace kann ein Einsicht bringen den man ohne Profratrace keine Schance hat.
Ohne Profitrace ist man grundsätzlich blind.

Es gehört schon sehr viel Erfahrung dazu die Telegramme und die Buspegel auszuwerten.

So viel Erfahrung braucht man nicht. Die Bedienung von Profitrace ist gut. Es hat uns geholfen obwohl wir keine Eksperten sind.

Manchmal müssen die Timings geändert werden, wenn die Slaves in die Jahre gekommen sind.

Manchmal ?
Selbstverständlich müssen die Busparameter immer neu Berechnet werden bei jeden Änderung in den Profibus Netz.
Die korrekte TTR ist A.u.O für Profibus.

Oft hilft es schon einige Parameter zu ändern, z.B Retry_limit auf 5, dann sieht man welcher Slave wie oft
angesprochen wird bevor die CPU in stop geht.

Retry Limit zu erhöhen ist eine bekannte Trick um den Profibus am laufen zu halten bis man die Fehler gefunden und beseitigt hat.

 

[Lipperlandstern]

Kann ich bestätigen, vor allem wenn die Stecker älter als 12 Jahre sind.

Als diverse Hersteller damals Profibusstecker produziert haben, war anscheinend keiner dabei der Ahnung von Übergangswiderständen und Kontaktmaterial hatte .
Ich hab sie alle erlebt und habe über 200 Stecker eingesammelt die alle das gleich Problem haben.

Ich gehe an keinen Bus mehr ohne Analyzer. Der Glaube, "wenn alle LED grün sind", muss alles richtig sein ist falsch.

Profibuskabel in Schleppketten ist auch so ein Kandidat. Gehört auch alle paar Jahre gewechselt

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mieten wird nicht viel bringen. Es gehört schon sehr viel Erfahrung dazu die Telegramme und die Buspegel auszuwerten.
Manchmal müssen die Timings geändert werden, wenn die Slaves in die Jahre gekommen sind.
Oft hilft es schon einige Parameter zu ändern, z.B Retry_limit auf 5, dann sieht man welcher Slave wie oft
angesprochen wird bevor die CPU in stop geht.

Anbei eine Tabelle wie ich das bei Procentec gelernt habe.

Dass ist mit dem Erhöhen von max_retry_limit Fehler ausblenden kann ist verständlich, ich würde das aber nicht als "bessere" Einstellung bezeichnen.

Weißt du was zum Hintergrund, warum bei "in die Jahre gekommenen" Slaves Zeiten wie min_tsdr und tqui erhöht werden sollen? Wenn die Flanken da beispielsweise generell nicht mehr so steil sind wie im Neuzustand, dann ist das doch auch bei einzelnen Bits der Fall, und nicht nur zwischen den Sequenzen.

 

[rlw]

Dass ist mit dem Erhöhen von max_retry_limit Fehler ausblenden kann ist verständlich, ich würde das aber nicht als "bessere" Einstellung bezeichnen.

Weißt du was zum Hintergrund, warum bei "in die Jahre gekommenen" Slaves Zeiten wie min_tsdr und tqui erhöht werden sollen? Wenn die Flanken da beispielsweise generell nicht mehr so steil sind wie im Neuzustand, dann ist das doch auch bei einzelnen Bits der Fall, und nicht nur zwischen den Sequenzen.

Besonders die ET200U Koppler fallen damit auf, dass sie nicht mehr so reagieren wie im Neuzustand.
Man muss für den "Start der Antwort" einige Bitzeiten einschieben weil der Slave einfach nicht mehr so schnell antwortet.
Für die "Beruhigungszeit" gilt das gleiche, da wird nicht so schnelle beendet wie es sein sollte.

Mit der Erhöhung von max_retry erreicht man, das Störungen auf dem Bus nicht gleich nach der 2. Anfrage des Masters
zum austragen des Slave aus der Liste führen.
Man kann in diesen Fällen in den Telegrammaufzeichnungen gut beobachten , wie der Master 3-4 mal versucht den Slave anzusprechen, bis dieser
Antwortet.
Mir sind die "paar" nanosekunden Laufzeitverlängerung lieber als ein Slave der abgemeldet wird.
Wenn ich mir mit dem Analyzer ansehe, wie hoch die max.Zahl der Retries für die einzelnen Koppler ist , kann ich mich an die Arbeet machen und
den Bus in Ordnung bringen.

 

[rlw]

Warum nicht ? Auch eine kurze Verwendung von die Profitrace kann ein Einsicht bringen den man ohne Profratrace keine Schance hat.
Ohne Profitrace ist man grundsätzlich blind.

So viel Erfahrung braucht man nicht. Die Bedienung von Profitrace ist gut. Es hat uns geholfen obwohl wir keine Eksperten sind.

Manchmal ?
Selbstverständlich müssen die Busparameter immer neu Berechnet werden bei jeden Änderung in den Profibus Netz.
Die korrekte TTR ist A.u.O für Profibus.

Retry Limit zu erhöhen ist eine bekannte Trick um den Profibus am laufen zu halten bis man die Fehler gefunden und beseitigt hat.

Ich muss dir recht geben mit der Bedienung, aber die Beurteilung und Auswertung der Pegel und Datentelegramme setzt
doch einiges an Kenntnissen und Erfahrung voraus.

Wenn du z.B. im Analyzer einen Ausfall im Slave 22 erkennst, dann heisst dass noch lange nicht, dass dieser Probleme hat.
Es kann auch sein dass genau zu dem Zeitpunkt wo der Master diesen Slave 22 abfragen wollte, eine Unterbrechung durch
Erschütterungen im Stecker von Slave 7 stattgefunden hat und die nachfolgenden Stationen nicht mehr erreichbar waren.

Da wurden schon zig Slaves "unschuldig" verdächtigt und ausgetauscht.

 

[daMichael]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen!
erstmal vielen Dank für das ganze Feedback, ich hab mir das alles gerade durchgelesen.
Ich werde im Laufe des Tages mal auf alles antworten!

Hallo daMichael,
das hört sich erst mal seltsam an. Ich drücke das mal anders aus, um es besser zu verstehen. Du baust einen Busfehler ein, in dem Du den Terminator ausschaltest und der Bus läuft hoch. Das heiß für mich, dass noch weitere Fehler drin sein müssen. Als erstes versuche ich mal die physikalischen Grundlagen zu überprüfen. Im zweiten Schritt dann die Hochlaufphase.
Busabschluß an jedem Segment Anfang und Ende auf ein. Also dort wo sich nur noch ein Kabel befindet. Dabei muss der Stecker richtig angeschlossen sein. Nur am Eingang wirkt der Busabschluß. Das könnte eine der Ursachen sein, manchmal ist das Kabel im Stecker am Ausgang angeschlossen. Vielleicht kannst Du Bilder machen und diese hier rein stellen, damit wir den Punkt abhaken können.
Repeater: Ich gehe mal von einem Siemens Repeater aus. Ist er am Ende so ist der Eingang links. Das zweite Segment wäre unten auch links anzuschließen. Sitzt der Repeater in der Mitte, so könnte oben und unten auch der rechte Anschluss belegt sein.
Wenn ich von Dir ein o.k. bekomme gehen wir in die nächste Runde.

Viel Erfolg Hans-Ludwig Göhringer

Genau, wenn ich den Terminator ausschalte, läuft der Bus hoch.
Wir haben die Verkabelung an sich geprüft, ich werde jedoch noch einmal genauer hinschauen, ob an den Steckern auch die Verkabelung passt. Wegen Bildern frage ich nach, ob ich welche machen darf.
Genau, es sind Siemens Repeater, das habe ich nicht erwähnt. Die Repeater sitzen jeweils in der Mitte, es sind alle 4 Anschlussstellen belegt.

Vielen Dank!
Michael

 

[daMichael]

Einfache Regeln sind: wenn nur ein Kabel in der Stecker geht muss das Kabel in den oberen Eingang bzw in den Eingang wo der
Pfeil nach "rein" zeigt.
Immer wenn nur ein Kabel reingeht muss muss der Abschlusswiderstand auf ON stehen.

Nach meinen 20 Jahren Bus-Erfahrung kann ich sagen, dass wir hartnäckige Fehler nur mit einem Busanalyzer beseitigen.
Wir benutzen den Profitrace von Procentec.
Die Fehler liegen zu 90% in der Verkabelung und in den Steckern, defekte Slaves sind selten.

Erst nach 2009 wurden z.B. die Schiebeschalter mit Goldkontakten ausgestattet.

Ich habe mal bei einer Anlage 70 Stecker getauscht. Die Mikroskopaufnahmen der Kontrakte zeigten einen grauenhaftes
Bild, abwohl die Anlage in einem Reinraum steht.

Vielen Dank! ich werde mir das nochmal anschauen!

Wir haben einen Profibustester PB3 hier, den versuche ich aktuell zum laufen zu bekommen. Hier fehlt mir jedoch noch der Treiber, ich habe mit dem Hersteller bereits Kontakt aufgenommen deswegen.

+1.
Hatte auch ein Fehler den wir ohne die Profitrace nie lokalisiert hätten.
Eventuell kann man die Profitrace mieten.


OMG !
Das erklärt einiges.

Eventuell wäre das auch eine Option.

Mieten wird nicht viel bringen. Es gehört schon sehr viel Erfahrung dazu die Telegramme und die Buspegel auszuwerten.
Manchmal müssen die Timings geändert werden, wenn die Slaves in die Jahre gekommen sind.
Oft hilft es schon einige Parameter zu ändern, z.B Retry_limit auf 5, dann sieht man welcher Slave wie oft
angesprochen wird bevor die CPU in stop geht.

Anbei eine Tabelle wie ich das bei Procentec gelernt habe.

Bei schwierigen Fälle würde ich jemand von Procentec dazuholen, oder mich.

Softing kann's auch.

Wenn ich Messwerte habe, würde ich diese hier mal posten, ich persönlich habe hier definitiv zu wenig Erfahrung.
Ich werde mal nachschauen, was beim Retry Limit eingestellt ist.
Vielen Dank, die Tabelle schau ich mir an.

Hast du also beruflich viel mit Procentec zu tun?

Wir haben einen Profibustester von Softing hier, den würde ich gerne mal testen.

 

[daMichael]

Braucht die Anlage wirklich sooo viel Ruhestrom, daß sich das Ausschalten gegenüber dem Risiko des nicht wieder Anlaufens/teurem Anlagenstillstands lohnt? Reicht nicht auch einfach Notaus aktivieren?
Die meisten unserer SPS werden nie ausgeschaltet. Bei denen mit Daten-Verarbeitung haben wir sogar USV installiert um Stromausfälle bis 20 Minuten zu überbrücken. Einige Schaltschränke sind auch in feuchten Räumen mit 8°C Raumtemperatur, da benötigen die Schaltschränke ständig im Inneren etwas Wärmeleistung gegen Betauung/Kondenswasser und die Folgeschäden.
Der gefährlichste Moment im Leben von Elektronikkomponenten ist das Strom-Einschalten. Man muß teure Anlagen nicht unnötig oft diesem Risiko "Strom einschalten" aussetzen.


STOP-Ursachen kann man im Diagnosepuffer der CPU nachlesen. Da fehlt wohl irgendeiner der üblichen OB.
"Weihnachtsbaum" kann auch dazu führen, daß sich die CPU nie wieder erholt/rücksetzen läßt!


Schau mal in den OB100, da ist vermutlich eine Schleife programmiert, die auf irgendwas wartet was nicht kommt. Prüfe: Muß das wirklich sein??


Für die Abschlußwiderstände gibt es Regeln. Vielleicht sind auch zu viele Abschlußwiderstände eingeschaltet (Teilnehmer mit einfachen Abschluß-Einschaltern anstatt -Umschaltern)? Mehr als 2 Profibuskabel auf einem Anschlußpunkt (also Sternstruktur!)? Profibuskabel auch auf der PG-Buchse der Repeater?
siehe Systemhandbuch PROFIBUS Netzhandbuch


Wir haben die Erfahrung, daß bei sich häufenden Profibus-Fehlern in > 10 Jahre alten Anlagen konsequentes Austauschen ALLER Profibus-Stecker zuverlässiger hilft als wochenlanges 'rumdocktern.

Harald

Gute Frage. Wieso genau wir diese immer ausschalten, kann ich auch nicht sagen, ich bin noch neu hier im Betrieb.
Feuchte Räume haben wir hier nicht, das ist jetzt nicht das Problem.

Im Diagnosepuffer hatte ich den OB80 drin und "Dezentrale Peripherie: Ende der Synchronistion mit einem DP-Master/IO-Controller".
Der OB80 kommt nicht immer dabei.


Im OB100 ist keine Schleife, wir wir nur ein Bit gesetzt.

Die Abschlusswiderstände passen (bis auf den einen, den wir deaktivieren müssen) und Sternstruktur haben wir auch keine. Ich werde mal in das Handbuch schauen, danke sehr!

Eventuell wäre das Tauschen aller Stecker mal eine Option, die Anlage ist auch über 20 jahre alt.

 

[daMichael]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kann ich bestätigen, vor allem wenn die Stecker älter als 12 Jahre sind.

Als diverse Hersteller damals Profibusstecker produziert haben, war anscheinend keiner dabei der Ahnung von Übergangswiderständen und Kontaktmaterial hatte .
Ich hab sie alle erlebt und habe über 200 Stecker eingesammelt die alle das gleich Problem haben.

Ich gehe an keinen Bus mehr ohne Analyzer. Der Glaube, "wenn alle LED grün sind", muss alles richtig sein ist falsch.

Interessant, dass das wirklich so ein großes Problem ist. Ein paar haben wir mittlerweile an besagter Anlage getauscht, eventuell wäre es interessant, mal alle zu tauschen.
Ja, so einfach ist es nicht.

Das wiederhole ich seite 10 Jahren immer wieder, wie z. B. hier:

https://digital.industrielle-automation.net/industrielle-automation-4-2015/56663135/27

Aber manche Digital Natives kennen halt nur zwei Zustände "geht" und "geht nicht".

naja, Hauptsache die Anlage läuft. Aber so binär ist das ganze leider nicht.
Danke für den Link, schau ich mal rein!

Wir haben sporadisch Busausfälle bei einer Kübelbahn, die aber teilweise über Funk läuft. Bisher dachte ich, das Wlan der LKW's, die darunter entladen, sei das Problem, aber da die Anlage von 2002 ist, werde ich die Busstecker erneuern. Der Leitrechner (Windows NT 4.0) ist auch aus der Zeit und wird, wie Harald schon erwähnt hat, niemals ausgeschaltet. Die Fehler, die dann auftreten, kennen wir zur genüge.

Vielleicht bringt das was.
Aktuell lassen wir die Anlage auch eingeschaltet, aber den Fehler sollten wir trotzdem beheben.

Warum nicht ? Auch eine kurze Verwendung von die Profitrace kann ein Einsicht bringen den man ohne Profratrace keine Schance hat.
Ohne Profitrace ist man grundsätzlich blind.

So viel Erfahrung braucht man nicht. Die Bedienung von Profitrace ist gut. Es hat uns geholfen obwohl wir keine Eksperten sind.

Manchmal ?
Selbstverständlich müssen die Busparameter immer neu Berechnet werden bei jeden Änderung in den Profibus Netz.
Die korrekte TTR ist A.u.O für Profibus.

Retry Limit zu erhöhen ist eine bekannte Trick um den Profibus am laufen zu halten bis man die Fehler gefunden und beseitigt hat.

Also mit irgendeinem Tool wollen wir definitiv an den Bus, vielleicht finden wir da ein paar Anhaltspunkte.

 

[Lipperlandstern]

In deinen Antworten steht jetzt irgendwo das die Anlage 20 Jahre alt ist. Da würde ich sofort und ohne irgendetwas anderes zu machen ALLE Stecker tauschen und die Kabel gleich mit. Zumindest aber die Kabel an den Anschlussstellen neu abisolieren

 

[daMichael]

Profibuskabel in Schleppketten ist auch so ein Kandidat. Gehört auch alle paar Jahre gewechselt

Haben wir hier an der Anlage keine, aber die Kabel gehen auch durch die Maschine. Wir haben testweise einzelne Leitungen durch eine Freileitung ersetzt zum testen. Bei einem Teil konnten wir den Bus wieder terminieren und hatten keinen Busfehler mehr. Der Zustand hielt ungefähr 12 Stunden an..

Dass ist mit dem Erhöhen von max_retry_limit Fehler ausblenden kann ist verständlich, ich würde das aber nicht als "bessere" Einstellung bezeichnen.

Weißt du was zum Hintergrund, warum bei "in die Jahre gekommenen" Slaves Zeiten wie min_tsdr und tqui erhöht werden sollen? Wenn die Flanken da beispielsweise generell nicht mehr so steil sind wie im Neuzustand, dann ist das doch auch bei einzelnen Bits der Fall, und nicht nur zwischen den Sequenzen.

Vielleicht wäre das auch ein Anhaltspunkt. Aber gegen die Alterungseffekte kann man sonst nicht viel machen, oder?

Besonders die ET200U Koppler fallen damit auf, dass sie nicht mehr so reagieren wie im Neuzustand.
Man muss für den "Start der Antwort" einige Bitzeiten einschieben weil der Slave einfach nicht mehr so schnell antwortet.
Für die "Beruhigungszeit" gilt das gleiche, da wird nicht so schnelle beendet wie es sein sollte.

Mit der Erhöhung von max_retry erreicht man, das Störungen auf dem Bus nicht gleich nach der 2. Anfrage des Masters
zum austragen des Slave aus der Liste führen.
Man kann in diesen Fällen in den Telegrammaufzeichnungen gut beobachten , wie der Master 3-4 mal versucht den Slave anzusprechen, bis dieser
Antwortet.
Mir sind die "paar" nanosekunden Laufzeitverlängerung lieber als ein Slave der abgemeldet wird.
Wenn ich mir mit dem Analyzer ansehe, wie hoch die max.Zahl der Retries für die einzelnen Koppler ist , kann ich mich an die Arbeet machen und
den Bus in Ordnung bringen.

Für die Telegrammaufzeichnungen brauche ich vermutlich wieder einen Profibustester?