# Profibus Busfehler



## daMichael (20 Mai 2022)

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 (20 Mai 2022)

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 (20 Mai 2022)

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 (20 Mai 2022)

rlw schrieb:


> 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.



rlw schrieb:


> 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 (20 Mai 2022)

JesperMP schrieb:


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


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 (20 Mai 2022)

daMichael schrieb:


> 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.



daMichael schrieb:


> 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!



daMichael schrieb:


> 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??



daMichael schrieb:


> 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



daMichael schrieb:


> 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 (20 Mai 2022)

PN/DP schrieb:


> 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 (20 Mai 2022)

rlw schrieb:


> ...  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 (20 Mai 2022)

rlw schrieb:


> 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.
> ...


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 (20 Mai 2022)

rlw schrieb:


> 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.


rlw schrieb:


> 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.


rlw schrieb:


> 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.


rlw schrieb:


> 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 (20 Mai 2022)

rlw schrieb:


> 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.
> ...


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


----------



## Thomas_v2.1 (20 Mai 2022)

rlw schrieb:


> 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.
> ...


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 (22 Mai 2022)

Thomas_v2.1 schrieb:


> 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 (22 Mai 2022)

JesperMP schrieb:


> 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.
> ...



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 (23 Mai 2022)

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!



Hans-Ludwig schrieb:


> 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.
> ...


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 (23 Mai 2022)

rlw schrieb:


> 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.
> 
> ...


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.



JesperMP schrieb:


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


Eventuell wäre das auch eine Option.



rlw schrieb:


> 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.
> ...


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 (23 Mai 2022)

PN/DP schrieb:


> 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.
> 
> ...



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 (23 Mai 2022)

rlw schrieb:


> 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.
> ...


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.



Gerhard Bäurle schrieb:


> 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!



dekuika schrieb:


> 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.



JesperMP schrieb:


> 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.
> ...


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


----------



## Lipperlandstern (23 Mai 2022)

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 (23 Mai 2022)

Lipperlandstern schrieb:


> 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..



Thomas_v2.1 schrieb:


> 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?



rlw schrieb:


> 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.
> 
> ...


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


----------



## Blockmove (23 Mai 2022)

Lipperlandstern schrieb:


> 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


100% ACK
Lass ich bei Problemen an alten Anlagen auch generell machen.
Geht in den allermeisten Fällen schneller als eine Fehlersuche mit Pegel und Telegrammanalyse.


----------



## daMichael (23 Mai 2022)

rlw schrieb:


> 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.
> ...


Ja das ist nicht so einfach. Wenn ich hier Werte hätte, würd ich diese hier posten.


----------



## daMichael (23 Mai 2022)

Lipperlandstern schrieb:


> 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


Ja genau. Das habe ich am Freitag vergessen zu erwähnen, tut mir leid.
Also ist auch die Lebensdauer der Kabel begrenzt? 
Bei den getauschten Steckern wurden die Anschlussstellen neu abisoliert.


Blockmove schrieb:


> 100% ACK
> Lass ich bei Problemen an alten Anlagen auch generell machen.
> Geht in den allermeisten Fällen schneller als eine Fehlersuche mit Pegel und Telegrammanalyse.


Ich werd mal mit den Elektrikern reden.

Danke euch!


----------



## PN/DP (23 Mai 2022)

daMichael schrieb:


> Also ist auch die Lebensdauer der Kabel begrenzt?


Nein, eigentlich nicht, kommt aber "drauf" an. Wenn der Stecker ausgetauscht wird, dann ist zumindest das Abschneiden von ein paar cm und neu Abisolieren mit dem Spezialwerkzeug sinnvoll. Da sieht man dann auch, ob man blankes Kupfer und Schirmgeflecht findet (ob die Drähtchen gut blank sind) oder im Kabel schon korrodiert sind, z.B. schwarz oder grau angelaufen.

Bei Fehlersuchen im Schaltschrank werden manchmal die Profibus-Kabel aus den Verdrahtungskanälen herausgerissen und später mit extrem engem Biegeradius (kurz vorm Aderbruch) wieder in die Kanäle zurückgestopft, und das manchmal mehrmals im Leben der Kabel. Da könnte man über den Austausch des Kabels nachdenken. Oder wenn viele kurze Kabelstücken/Schlaufen zwischen Teilnehmern sind (z.B. zwischen Frequenzumrichtern), das wurde vor 20 Jahren vielleicht auch eher billig als gut montiert, das könnte man auch gleich nochmal neu und gut machen.

Harald


----------



## rlw (23 Mai 2022)

Die Kabel hab ich nur selten als Fehler ausgemacht, es sei denn die lagen in Öl oder waren gequescht.
Der Übeltäter ist meist der Stecker. Es gab zu anfang schon die Stecker von ERNI, in gelb und grau.
Da gab es keine Terminierungsschalter, die Terminierung war eingebaut bzw. nicht vorhanden.
Da musste man beim Aufbau festlegen welcher Stecker reinkommt.
Diese Bussysteme laufen heute noch .

Das hat sich aber nicht durchgesetzt, weil man die Bussegmente zum Test/Fehlersuche nicht auftrennen konnte.

Es wurden in den Anfängen der Bussysteme, aus Kostengründen auch Stecker eingesetzt, die zwar mit Schiebeschalter 
terminieren konnten aber nicht auftrennen.  Der Bus war dann oft mehrfach terminiert und lief auf dem "Zahnfleich".


----------



## DeltaMikeAir (23 Mai 2022)

rlw schrieb:


> Die Kabel hab ich nur selten als Fehler ausgemacht, es sei denn die lagen in Öl oder waren gequescht.
> Der Übeltäter ist meist der Stecker.


Es kommt wohl auf das Umfeld an. Wir hatten schon ( in Brauereien ) von Mäusen angefressene Profibuskabel. Aber zu 99%
sind es die Stecker. Ich isoliere sie auch immer gleich neu ab, mit dem Werkzeug ist das ja auch eine Sache von unter einer Minute.
Bzw. oft *muss* ich sie auch neu abisolieren da man vor 20 Jahren noch überwiegend die PB-Stecker mit Schraubkontakten eingesetzt hat und ich nur noch die mit Schneidklemmen verwende.




PS:
Ich hatte auch schon mal einen neuen Profibusstecker bei dem intern einen Haarriss auf der Platine war.


----------



## rlw (23 Mai 2022)

daMichael schrieb:


> Hast du also beruflich viel mit Procentec zu tun?
> 
> Wir haben einen Profibustester von Softing hier, den würde ich gerne mal testen.


Ich habe mit dem PBT3 angefangen *und* dem Profitrace Telegramm-Analyzer von Procentec.
Später hab ich das durch den Profitrace-2 ersetzt, der beides konnte ,  Oszilloskop-Funktion und Telegramme.
Die meisten Kunden waren so beeindruckt, dass ich denen auch ein Gerät mit Einweisung verkaufen konnte.
Die Instandhaltung nutzt das jetzt im Rahmen der "vorbeugenden Instandhaltung".
In den Pflichtenheften steht jetz auch dass bei eiiner Neuanlage ein Nachweis über einen ganzen Tag geführt werden muss,
bei dem keine Telegrammwiderholungen und Fehler auftreten dürfen.

Das Protokoll dass der Profitrace ausspuckt ist dann schon mal 150 Seiten  lang

Der Tetster von Softing  wird dass sicher auch können.


----------



## PN/DP (23 Mai 2022)

daMichael schrieb:


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


Die RUN-LED blinkt solange die CPU im ANLAUF ist, also in OB100/OB101/OB102. Das sollte nicht wesentlich länger als eine Minute dauern. Wenn RUN viel länger blinkt, dann kann auch irgendwas falsch projektiert sein oder der Anlauf wird durch Warteschleifen in OB100/OB101/OB102 verlängert. Oder die CPU ist in DEFEKT (dann blinkt auch STOP) oder ein Firmwarefehler??

Vielleicht ist eine extrem lange Wartezeit auf die Fertigmeldung der Baugruppen projektiert? (HW Konfig > CPU 416 ... > Anlauf, Standard ist 650 ( x 100ms = 65 Sekunden )
Das würde bedeuten, daß schon früher ein Programmierer (vom Hersteller?) Anlaufprobleme festgestellt hatte.



daMichael schrieb:


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


Gibt es da auch OB101 oder OB102?



daMichael schrieb:


> 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.


Da wäre mal der genaue und komplette Meldetext interessant, der zur Anforderung des OB80 führt. Der Diagnosepuffer kann als Textdatei gespeichert werden und hier (auszugsweise) hochgeladen oder gepostet werden. Am besten alle Diagnosepuffereinträge ab Netz-EIN.
Ist im OB80 was programmiert?

Harald


----------



## rlw (23 Mai 2022)

Und so darf es auf gar keinen Fall aussehen!!!!!!


----------



## daMichael (23 Mai 2022)

rlw schrieb:


> Die Kabel hab ich nur selten als Fehler ausgemacht, es sei denn die lagen in Öl oder waren gequescht.
> Der Übeltäter ist meist der Stecker. Es gab zu anfang schon die Stecker von ERNI, in gelb und grau.
> Da gab es keine Terminierungsschalter, die Terminierung war eingebaut bzw. nicht vorhanden.
> Da musste man beim Aufbau festlegen welcher Stecker reinkommt.
> ...


okey danke.
also unsere stecker sollten auch wieder auftrennen, wenn die schalter auf off stehen.
aber interessant, was es alles gibt.


PN/DP schrieb:


> Nein, eigentlich nicht, kommt aber "drauf" an. Wenn der Stecker ausgetauscht wird, dann ist zumindest das Abschneiden von ein paar cm und neu Abisolieren mit dem Spezialwerkzeug sinnvoll. Da sieht man dann auch, ob man blankes Kupfer und Schirmgeflecht findet (ob die Drähtchen gut blank sind) oder im Kabel schon korrodiert sind, z.B. schwarz oder grau angelaufen.
> 
> Bei Fehlersuchen im Schaltschrank werden manchmal die Profibus-Kabel aus den Verdrahtungskanälen herausgerissen und später mit extrem engem Biegeradius (kurz vorm Aderbruch) wieder in die Kanäle zurückgestopft, und das manchmal mehrmals im Leben der Kabel. Da könnte man über den Austausch des Kabels nachdenken. Oder wenn viele kurze Kabelstücken/Schlaufen zwischen Teilnehmern sind (z.B. zwischen Frequenzumrichtern), das wurde vor 20 Jahren vielleicht auch eher billig als gut montiert, das könnte man auch gleich nochmal neu und gut machen.
> 
> Harald


auch danke fürs Feedback.
Die Kabelenden sahen noch gut aus.



DeltaMikeAir schrieb:


> Es kommt wohl auf das Umfeld an. Wir hatten schon ( in Brauereien ) von Mäusen angefressene Profibuskabel. Aber zu 99%
> sind es die Stecker. Ich isoliere sie auch immer gleich neu ab, mit dem Werkzeug ist das ja auch eine Sache von unter einer Minute.
> Bzw. oft *muss* ich sie auch neu abisolieren da man vor 20 Jahren noch überwiegend die PB-Stecker mit Schraubkontakten eingesetzt hat und ich nur noch die mit Schneidklemmen verwende.
> 
> ...


Was es alles gibt.
Mäuse haben wir hier zum Glück nicht.
Das Werkzeug haben wir auch hier, damit klappt es gut.
Wie hat sich der Haarriss dann gezeigt? Also vom verhalten?


----------



## DeltaMikeAir (23 Mai 2022)

daMichael schrieb:


> Mäuse haben wir hier zum Glück nicht.


Das haben die in der Brauerei auch gesagt. Ich hatte hier irgendwo auch mal ein Foto eingestellt, bei dem die Maus noch am Kabel hing.
Leider hatte sie das falsche Kabel erwischt ☠️


----------



## daMichael (23 Mai 2022)

rlw schrieb:


> Ich habe mit dem PBT3 angefangen *und* dem Profitrace Telegramm-Analyzer von Procentec.
> Später hab ich das durch den Profitrace-2 ersetzt, der beides konnte ,  Oszilloskop-Funktion und Telegramme.
> Die meisten Kunden waren so beeindruckt, dass ich denen auch ein Gerät mit Einweisung verkaufen konnte.
> Die Instandhaltung nutzt das jetzt im Rahmen der "vorbeugenden Instandhaltung".
> ...


Ist bei mir halt auch ein PBT3.
Eventuell gibt es hier auch mal noch ein neueres Gerät, aber jetzt dann möchte ich erst einmal den PBT3 dranhängen, und schauen, was ich rausbekomme.



PN/DP schrieb:


> Die RUN-LED blinkt solange die CPU im ANLAUF ist, also in OB100/OB101/OB102. Das sollte nicht wesentlich länger als eine Minute dauern. Wenn RUN viel länger blinkt, dann kann auch irgendwas falsch projektiert sein oder der Anlauf wird durch Warteschleifen in OB100/OB101/OB102 verlängert. Oder die CPU ist in DEFEKT (dann blinkt auch STOP) oder ein Firmwarefehler??
> 
> Vielleicht ist eine extrem lange Wartezeit auf die Fertigmeldung der Baugruppen projektiert? (HW Konfig > CPU 416 ... > Anlauf, Standard ist 650 ( x 100ms = 65 Sekunden )
> Das würde bedeuten, daß schon früher ein Programmierer (vom Hersteller?) Anlaufprobleme festgestellt hatte.
> ...


Also OB100 war drin, OB101 haben wir auch eingefügt.
Beim OB102 heißt es, die CPU unterstützt diese Ebene nicht.
Wie haben auch die CPU getauscht, das hat keine Besserung gebracht. Nun ist die alte CPU wieder drin.

Wenn ich wieder einen Fehler habe, schaue ich, dass ich die Meldetexte besorge.

Im OB80 ist ein STP-drin, den haben wir aber bereitsherausgenommen. Ansonsten wird hier nur die OB80_FLT_ID abgefragt. Und einige OB_80_XXXX Werte geladen, aber nicht verwendet. Meines Wissens hatten wir seitdem keinen STOP mehr, er ist vorher aber auch nicht immer aufgetreten..


----------



## daMichael (23 Mai 2022)

rlw schrieb:


> Und so darf es auf gar keinen Fall aussehen!!!!!!


oha
bei uns sollten sie richtig drauf sein, also so siehts zum glück nicht aus


----------



## daMichael (23 Mai 2022)

DeltaMikeAir schrieb:


> Das haben die in der Brauerei auch gesagt. Ich hatte hier irgendwo auch mal ein Foto eingestellt, bei dem die Maus noch am Kabel hing.
> Leider hatte sie das falsche Kabel erwischt ☠️


oh, das kann ich mir vorstellen.


----------



## DeltaMikeAir (23 Mai 2022)

daMichael schrieb:


> Also OB100 war drin, OB101 haben wir auch eingefügt.
> Beim OB102 heißt es, die CPU unterstützt diese Ebene nicht.
> Wie haben auch die CPU getauscht, das hat keine Besserung gebracht.


Ihr solltet ja keinen OB101 einfügen sondern nur prüfen, ob dieser vorhanden ist und wenn ja, was drin steht.



daMichael schrieb:


> Beim OB102 heißt es, die CPU unterstützt diese Ebene nicht.


OB101/OB102 wird nicht (mehr) von allen CPU´s unterstützt. Ich meine nur auf denen mit dem alten Schlüsselschalter für RUN/STOP.......


----------



## DeltaMikeAir (23 Mai 2022)

daMichael schrieb:


> Im OB80 ist ein STP-drin, den haben wir aber bereitsherausgenommen.


OB80 => Zeitfehler

Interessant wäre der komplette Auszug des Meldepuffers der CPU


----------



## daMichael (24 Mai 2022)

DeltaMikeAir schrieb:


> Ihr solltet ja keinen OB101 einfügen sondern nur prüfen, ob dieser vorhanden ist und wenn ja, was drin steht.
> 
> 
> OB101/OB102 wird nicht (mehr) von allen CPU´s unterstützt. Ich meine nur auf denen mit dem alten Schlüsselschalter für RUN/STOP.......


Also im OB100 und OB101 wird nur ein Start-Bit gesetzt für den Anlauf.


DeltaMikeAir schrieb:


> OB80 => Zeitfehler
> 
> Interessant wäre der komplette Auszug des Meldepuffers der CPU


werde ich noch liefern, wenn ich nochmal an der Anlage bin.


----------



## ducati (24 Mai 2022)

daMichael schrieb:


> oha
> bei uns sollten sie richtig drauf sein, also so siehts zum glück nicht aus


"sollten" ???
Hast Du Dir wirklich *ALLE* angeschaut? *EIN* schlechter reicht aus, um Chaos zu verursachen. Ebenso bei Kabeln, eine schlechte Stelle, wersteckt, wo mans nicht sieht reicht aus.
Ansonsten halt noch Thema Potentialausgleich, wenn der Schrim bei den Profibussteckern beidseitig aufgelegt ist, braucht man zwingend nen ordentlichen Potentialausgleich zwischen den Komponenten/Anlagenteilen. Sonst zieht man sich den Potentialausgleich über den Schirm der Profibusleitung...


----------



## daMichael (30 Mai 2022)

ducati schrieb:


> "sollten" ???
> Hast Du Dir wirklich *ALLE* angeschaut? *EIN* schlechter reicht aus, um Chaos zu verursachen. Ebenso bei Kabeln, eine schlechte Stelle, wersteckt, wo mans nicht sieht reicht aus.
> Ansonsten halt noch Thema Potentialausgleich, wenn der Schrim bei den Profibussteckern beidseitig aufgelegt ist, braucht man zwingend nen ordentlichen Potentialausgleich zwischen den Komponenten/Anlagenteilen. Sonst zieht man sich den Potentialausgleich über den Schirm der Profibusleitung...


Mittlerweise wurde alle Stecker getauscht.
Wie äußert sich das, wenn da etwas nicht passt vom Potentialausgleich?


----------



## DeltaMikeAir (30 Mai 2022)

daMichael schrieb:


> Wie äußert sich das, wenn da etwas nicht passt vom Potentialausgleich?


Busteilnehmer können sporadisch oder dauerhaft gestört sein. Hin bis zur Zerstörung.


----------



## daMichael (30 Mai 2022)

Update:
Der Fehler wieder auf, nachdem die Anlage vier Tag lang gestanden ist. Dieses Mal wurde die Anlage jedoch nicht ausgeschaltet.
Die Anlage lief wieder, bis ich ins Büro gekommen, war der Fehler wieder weg. Es wurden ein Repeater und ein testweise nochmal ein Bus-Stecker getauscht, was ich mitbekommen habe, irgendwann lief es wieder. Was genau gemacht wurde, kann ich morgen früh erfragen.
Was genau ist anders, wenn die Anlage eingeschaltet ist, aber nicht produziert?
Kann es theoretisch sein, dass der Fehler auftritt, wenn die Umgebungstemperatur absinkt?
In der Halle hat es dann nur noch 18°C, und über vier Tage kann alles abkühlen.  Einerseits kann ich mir nicht vorstellen, dass das  für die Elektronik zu kalt ist.


----------



## daMichael (30 Mai 2022)

DeltaMikeAir schrieb:


> Busteilnehmer können sporadisch oder dauerhaft gestört sein. Hin bis zur Zerstörung.


Wie genau sieht der Potentialausgleich normalerweise aus? Hier kenn ich mich leider noch nicht so gut aus.


----------



## Plan_B (30 Mai 2022)

daMichael schrieb:


> Einerseits kann ich mir nicht vorstellen, dass das für die Elektronik zu kalt ist.


Aber Kontaktprobleme können getriggert werden. Z.B. durch die Volumenänderung mit der Temperatur.


----------



## daMichael (30 Mai 2022)

Plan_B schrieb:


> Aber Kontaktprobleme können getriggert werden. Z.B. durch die Volumenänderung mit der Temperatur.


Aber reichen da wirklich ein paar Grad aus?
Ich messe eventuell die Woche mal die Temperatur in den Schränken, und dann, wenn wir wieder ein paar Tage stehen.


----------



## JesperMP (30 Mai 2022)

Was sagt die Diagnosepuffer genau nach die letzte Fehler ?

Ich empfehle nochmals die Profitrace. Man kann es ständig an den Bus hängen lassen, und wenn ein Busfehler auftaucht kann es Kurven und Diagnosemeldungen abspeichern so dass man es spähter analysieren kann. Ohne die Profitrace ist man mehr oder weniger Blind und suche in die Nebel nach eine Ursache.


----------



## rlw (30 Mai 2022)

JesperMP schrieb:


> Was sagt die Diagnosepuffer genau nach die letzte Fehler ?
> 
> Ich empfehle nochmals die Profitrace. Man kann es ständig an den Bus hängen lassen, und wenn ein Busfehler auftaucht kann es Kurven und Diagnosemeldungen abspeichern so dass man es spähter analysieren kann. Ohne die Profitrace ist man mehr oder weniger Blind und suche in die Nebel nach eine Ursache.


Stimmt, Profitrace ist die richtige Wahl, aber man muss auch verstehen was einem die Telegramme und Pegel sagen wollen
und man muss verstehen was im Diagnosepuffer der SPS zu sehen ist.
Ich hatte schon in Beitrag #5 erwähnt dass manche Fehler nicht so einfach zu finden sind, auch wenn man das teuerste Equipment hat.


----------



## daMichael (30 Mai 2022)

Das Problem ist, dass relativ viel rumgesteckt wurde, und das Programm neu aufgespielt wurde heute Nacht.
Ich befürchte, dass ich die Meldungen nicht mehr bekomme. Oder bleiben die hier erhalten? Ansonsten werde ich morgen mal mit dem PG an die Anlage gehen


----------



## daMichael (30 Mai 2022)

JesperMP schrieb:


> Was sagt die Diagnosepuffer genau nach die letzte Fehler ?
> 
> Ich empfehle nochmals die Profitrace. Man kann es ständig an den Bus hängen lassen, und wenn ein Busfehler auftaucht kann es Kurven und Diagnosemeldungen abspeichern so dass man es spähter analysieren kann. Ohne die Profitrace ist man mehr oder weniger Blind und suche in die Nebel nach eine Ursache.





rlw schrieb:


> Stimmt, Profitrace ist die richtige Wahl, aber man muss auch verstehen was einem die Telegramme und Pegel sagen wollen
> und man muss verstehen was im Diagnosepuffer der SPS zu sehen ist.
> Ich hatte schon in Beitrag #5 erwähnt dass manche Fehler nicht so einfach zu finden sind, auch wenn man das teuerste Equipment hat.



Profitrace steht mir leider nicht zur Verfügung.
Ich werde es noch einmal mit dem PBT3 versuchen, nun scheint der Tester an einem PG tatsächlich mit der PBT3-Bediensoftware zu kommunizieren.


----------



## JesperMP (30 Mai 2022)

Wenn die Anlage weiter lief, warum das Programm neu aufspielen ?
In Panik das Programm einspielen wenn ein Problem auftaucht (und ohne die Diagnosepuffer zuerst zu abspeichern ?), das ist eine Zeigen dass die Leute keine Ahnung hat.
Hast du kein Remote-Verbindung zu die Anlage, so dass du sie in Fehlerfall unterstützen kann ? Dann hast du auch die Möglichkeit die Fehler zu beobacten wenn es noch ansteht.


----------



## daMichael (30 Mai 2022)

JesperMP schrieb:


> Wenn die Anlage weiter lief, warum das Programm neu aufspielen ?
> In Panik das Programm einspielen wenn ein Problem auftaucht (und ohne die Diagnosepuffer zuerst zu abspeichern ?), das ist eine Zeigen dass die Leute keine Ahnung hat.
> Hast du kein Remote-Verbindung zu die Anlage, so dass du sie in Fehlerfall unterstützen kann ? Dann hast du auch die Möglichkeit die Fehler zu beobacten wenn es noch ansteht.


Also ich glaube, sie haben es versucht, während sie nicht lief. Was genau alles passiert ist, kann ich auch nicht sagen.
Nein, leider kann ich noch nicht remote draufschauen, das wird mir erst noch eingerichtet.


----------



## rlw (30 Mai 2022)

daMichael schrieb:


> Profitrace steht mir leider nicht zur Verfügung.
> Ich werde es noch einmal mit dem PBT3 versuchen, nun scheint der Tester an einem PG tatsächlich mit der PBT3-Bediensoftware zu kommunizieren.



Mit dem PBT3 kannst du keine Telegramme auswerten uund aufzeichen.


----------



## JesperMP (30 Mai 2022)

Wieviel kostet Stillstand pro Stunde ?
Vergleiche dass mit eine Profitrace kaufen oder mieten, oder den Dienst von eine Eksperte kaufen.


----------



## daMichael (31 Mai 2022)

JesperMP schrieb:


> Wieviel kostet Stillstand pro Stunde ?
> Vergleiche dass mit eine Profitrace kaufen oder mieten, oder den Dienst von eine Eksperte kaufen.


puh, das will ich garnicht wissen
werde definitiv mal mit meinem vorgesetzten reden
Beim nächsten Anlauf bin ich auf jeden Fall dabei, werde dann erst einmal den Diagnose-Puffer auslesen, bevor ich irgendetwas an der Maschine mache


----------

