# Fehlersuche: Profibus Ausfall



## olitheis (22 Juni 2007)

Hallo,
vor einiger Zeit hatte ich nach Fehlerdiagnose für den Profibus-DP gefragt. Ich hatte dann auch die benötigten OB's und FB's dann im Programm angelegt usw., alles soweit i.O. Also wenn ein Fehler auftritt wurde die Anlage entsprechend gestoppt und es gibt eine Alarmmeldung. Des Weiteren hatte ich bei dem Besuch beim Kunden zuletzt alle DP Anschlußstecker ausgetauscht (in der Hoffnung, dass das Problem damit behoben ist). Ist es aber anscheinend nicht, der Kunde hat wieder mal angerufen, um mir mitzuteilen, dass wieder ein Busfehler aufgetreten ist. Jetzt habe ich folgende Fragen:
Kann ich die Fehler aus dem DB(125) abspeichern, um nachher den Fehler auszuwerten bzw. wie kann ich dem Problem am effektivsten auf die Schliche kommen?
Dazu muss ich jetzt noch folgendes sagen: Als ich die Änderungen im Programm eigepflegt habe, war ich mit meinem Laptop dort, konnte also die MC nicht beschreiben. Irgendwie hat der Kunde es geschafft, dass das "alte" Programm von der MC gelesen wurde, und somit meine Änderungen dahin sind.
Nächste Woche habe ich nochmal die Möglichkeit beim Kunden vor Ort die Sache zu untersuchen und meine Programmänderungen erneut einzuspielen.
Hat von Euch noch jeman einen Tip, wonach ich noch schauen sollte bez. des Fehlers. Ich habe dann zwar diese Diagnose drin, aber irgendwie komme ich damit auch nicht so richtig weiter.
Sorry für den viele Text
Vielen Dank
Oli


----------



## kiestumpe (22 Juni 2007)

olitheis schrieb:


> Hallo,
> Dazu muss ich jetzt noch folgendes sagen: Als ich die Änderungen im Programm eigepflegt habe, war ich mit meinem Laptop dort, konnte also die MC nicht beschreiben. Irgendwie hat der Kunde es geschafft, dass das "alte" Programm von der MC gelesen wurde, und somit meine Änderungen dahin sind.


 
Hallo Oli,

das riecht aber stark nach Stromausfall, wenn die MC erneut gelesen wurde. Dagegen hilft z.B. ne USV. Kannst du sowas (Stromausfall) evt nachvollziehen?


----------



## vladi (22 Juni 2007)

*DP Ausfall*

Hi,
vielleicht meinst Du FB125..
Bei Ausfälle gibt es Fehlercodes, die dann ausgewertet werden können, 
z.B. kan man die Fehler in einem DB abspeichern, und später anschauen.
Noch was: was für DP Ausfall? Also je nach DB Struktur, Baudrate usw.
kann vorkommen, das kurzzeitig DP Teilnehmer weg sind, und dann sofort
wieder kommen; die Frage ist ist das kritisch und muss man dann alles
abbrechen, oder macht man zuerst gar nichts. Falls solche Ausfälle in
ms Bereich nicht problematisch sind, lasse ich z.B. das so. Erst bei
längere Timeouts usw. würde ich dann reagieren.
Was passiert denn genau bei Deinem Kunden?

Gruss: Vladi


----------



## olitheis (22 Juni 2007)

@kiestumpe
ich denke der Kunde hatte zum "Beheben" des Fehlers (CPU Stop) die Spannungsversorgung weggenommen und neu eingeschaltet.

@vladi
den FB125 habe ich zusammen mit DB125 programmiert.
Du meinst also, dass es evtl. bei der Profibus Kommunikation Probleme geben könnte? Wie kann ich dass denn prüfen? Komisch ist halt nur, dass es bis vor kurzem alles Fehlerfrei gelaufen war. 


> Was passiert denn genau bei Deinem Kunden?


Also die Anlage bleibt undefinierbar wegen CPU Stop stehen. Man kann nicht sagen, dass es immer an der gleichen Stelle im Zyklus passiert. Manchmal passiert es sogar im Handbetrieb, wenn einfach nur das Hydraulikaggreat läuft, ohne dass eine Bewegung gefahren wird.
Wenn die CPU auf stop geht, geht der Kunde her und versucht durch Schalten der CPU auf Stop->Run oder halt mit "Power down" die Anlage wieder zum Laufen zu bringen, bevor ich informiert bin.
Deswegen auch meine Frage, ob man die Diagnose aus den DB125 speichern kann.
Leider habe ich auch nicht die genauen Fehler LED's der CPU und der Wago Slaves. Einmal habe ich aber diese Infos vom Kunden bekommen, in wiefern sie akurrat sind, kann ich nicht sagen:
CPU 315 2-DP:
SF-rot
Run-aus
Stop-an orange
BUSF-blinkt rot

Nochmals Danke


----------



## vladi (22 Juni 2007)

*DP Ausfall*

Hi,
Frage: CPU geht in STOP: wie geht denn das? Master oder Slave?
Denn: wenn du die benötigten OBs für die Fehlerbehandlung in alle
SPSen am Bus geladen hast, gibt es kein CPU STOP !!! Die
SPSen stehen nur, wenn die Fehler nicht abgefangen werden können, in den zugehörigen OB80, 82, 86, 85, 121, 122. Hast du die drin?

In den OBs wird auch Info über die Fehlerquelle geliefert(Lokaldatenbereich anschauen). 

DB125 kannst du in einem anderen DB kopieren, mit der BLK_MOVE Funktion, im Fehlerfall.

Gruss: Vladi


----------



## kiestumpe (22 Juni 2007)

Hallo,

auf das BLK-Move allein würde ich mich nicht verlassen, da nach Netzaus auch die Daten des anderen DB's weg sind. Du solltest dies auch noch irgendwie von der VISU aus in Alarmen wegschreiben bzw. sichern und diese Liste dann bei der Fehlersuche berücksichtigen.

Das mit den FehlerOB's ist schön und gut, funktioniert aber auch nicht 100%, zumindest musste ich die Erfahrung schon machen.
Trotzdem sollten sie natürlich alle vorhanden sein.
Auf der anderen Seite haben sie es sehr wahrscheinlich abgefange, der Kunde sah jedoch "rot", hat aus und eingeschaltet und danach war'n se weg und die Anlage stand ...

hth


----------



## olitheis (22 Juni 2007)

@ vladi
die CPU geht auf stop, da das program mit den geladenen OB's ja nich auf der MS geschrieben war, und nach Strom aus wurde das "alte" Programm aus der MS geladen.


----------



## Onkel Dagobert (22 Juni 2007)

Hallo Oli,

da von einer MC die Rede ist, handelt es sich um S7 der alten Bauform?


olitheis schrieb:


> ..Als ich die Änderungen im Programm eigepflegt habe, war ich mit meinem Laptop dort, konnte also die MC nicht beschreiben...


Macht man das denn nicht mit "RAM nach ROM kopieren"?!




olitheis schrieb:


> @ vladi
> die CPU geht auf stop, da das program mit den geladenen OB's ja nich auf der MS geschrieben war, und nach Strom aus wurde das "alte" Programm aus der MS geladen.


Keine Pufferbatterie drinn? Mit Pufferbatterie geht das Programm im RAM nur nach Urlöschen flöten.

Manchmal ist ein einzelner Busteilnehmer der Schuldige. Er stört den Bus so, dass durch diverse Diagnosen jeweils derjenige Slave als ausgefallen gemeldet wird, der vom Master gerade angesprochen wurde. Man kann es sich vorstellen wie ein "Kurzschluss" auf dem Bus. Der eigentliche Auslöser waren jedoch mehrere kleine (3kW) Gleichspannungsschütze, welche gleichzeitig schalteten. Selbst mit Schutzbeschaltung war der Effekt noch vorhanden. Nach Abtrennen aller Slaves eines bestimmten Typs trat der Fehler nicht mehr auf. Ich vermute, die Schutzbeschaltung am Busanschluss dieser Teilnehmer war etwas übersensibel oder ganz falsch ausgelegt.

Wie sieht denn die Umgebung in deinem Fall aus? Welche Busteilnehmer befinden sich am Bus? Buslänge, Busverlegung, ggf. Potenzialausgleich?


Gruß, Onkel


----------



## BiBi (23 Juni 2007)

hallo olitheis

wenn Du an dem Profibus einen Teilnehmer hast, welcher der letzte am Bus ist, der nur mit Netzspannung (230VAC) versorgt wird, und die Netzspannung kurze Unterbrechnungen hat, dann bleibt die CPU stehen. Die Fehler OBs sind dann, auch wenn vorhanden, wirkungslos. Du hast dann einen Teilnehmer am Bus, der den Bus nicht mehr mit Spannung versorgt und dadurch die Terminierung verloren geht. Das verursacht CPU STOP. Abhilfe: Entweder den Busteilnehmer mit SPS Spannung versorgen, oder nach dem Busteilnehmer einen aktiven Busabschluss einsetzen.


Gruß
BiBi


----------



## olitheis (26 Juni 2007)

@Onkel Dagobet
ja, es ist die alte Bauform.
Es gibt bei Step7 folgende Möglichkeiten:
Unter Zielsystem->
1. RAM nach ROM kopieren
2. Auf Memory Card speichern
welches ist die richtige Variante, wenn ich meine Änderungen auf der MC sichern möchte?


> Keine Pufferbatterie drinn? Mit Pufferbatterie geht das Programm im RAM nur nach Urlöschen flöten


Ich denke die probieren solange, bis die CPU sogar urgelöscht ist! denn die Batterie ist i.O.

Das hier habe ich nicht ganz verstanden, was meinst Du damit:


> Nach *Abtrennen aller Slaves eines bestimmten Typs* trat der Fehler nicht mehr auf. Ich vermute, *die Schutzbeschaltung am Busanschluss dieser Teilnehmer war etwas übersensibel oder ganz falsch ausgelegt*.


 
Ich habe hier einmal meine Busverdrahtung angefügt (als Screenshot+HW konfig Export). Die max. Kabellänge zwischen zwei Busteilnehmern beträgt ca. 15m. Wir haben 2 FU's (max 3 kw) und 4 Servoregler an der Anlage verbaut.
Aber wir gesagt, vorher nie Probleme gehabt(?).

Könnte es auch evtl. an einem ausgetauschen Slave liegen, den der Kunde mal gewechselt hat. (nicht genau der Gleiche, Firmware, usw...). Es ist wohl in letzter Zeit öfter vorgekommen, dass er versucht hat verschiedene Koppler auszuwechseln.

Ich hoffe, ihr könnt mir noch ein wenig helfen, da ich Morgen zum Kunden muss, und hoffe, das Problem eingrenzen zu können. 
denn wenn ich versuche den Diagnosepuffer aus der CPU zu deuten, kann ich irgendwie nicht so richtig ein konkretes Problem lokalisieren, weil  (meiner Meinung nach) diese Fehler nicht eindeutig zuzuordnen sind. Vielleicht deute ich sie auch falsch.

Vielen Dank
Oli


----------



## vladi (26 Juni 2007)

*DP Störungen*

Hi,
wie lang ist der ganze DP Strang? Viel Daten hin und her? 
Ich frage, weil: welche DP Baudrate fährst du? Oft genügt eine Stufe
runter zu gehen. 50 m Länge ist *max* bei 1,5 MBit!

Deine Konfiguration sieht wirklich nicht schlimm aus. 

Wenn du das Ganze bis jetzt hier beschriebene zusammenfasst, wird es
schon gehen. Lade die OBs rein, lass es laufen, prüfe alles, ziehe an den
Slaves mal die Spannung weg, und wieder ein; die SPS sollte weiter laufen.

Gruss: Vladi


----------



## olitheis (26 Juni 2007)

Hallo Vladi,

ich habe in der HW Konfig. nachgesehen: die Geschwindigkeit des MPI(1) steht auf 187.5kbit/s der CPU.
Bei den Slaves steht die Geschwindigkeit bei den Profibus Eigenschaften/Netzeinstellungen auf 1.5Mbit/s.

Wie weit kann ich denn mit den Geschwindigkeiten runtergehen (CPU+Slaves)?
Muss die CPU Geschwindgkeit mit der der Slaves übereinstimmen?

Wir fahren keine in der Anlage eigentlich keine zeitkritischen Zyklen.
Vielen Dank
Oli


----------



## Ralle (26 Juni 2007)

vladi schrieb:


> 50 m Länge ist *max* bei 1,5 MBit!



Wie kommst du darauf?
http://www.sps-forum.de/showpost.php?p=35760&postcount=2


----------



## dasding (26 Juni 2007)

Ralle schrieb:


> Wie kommst du darauf?
> http://www.sps-forum.de/showpost.php?p=35760&postcount=2


 

Also erst mal zu den 50m, das zählt bei MPI und das is bekanntlicher weise 187,5. Und dort darf man maximal 50m .
Und nun zu deinem Link....Wie kommst du darauf??:-D 
Schau mal hier im Handbuch auf der Seite 3-3, Kapitel3.1.1 und folgende *g*
http://support.automation.siemens.com/WW/view/de/1971286

@olitheis, ich versteh grad nicht wie deine Slaves auf 1,5 stehen aber am Mastersystem hängen welches 187,5 hat??? Wie gehtn das.
Am besten machst alles auf DP->MPI is mist 

EDIT: aber wenn ich mir dein cfg file ansehe passt doch alles....steht beides auf DP -> 1,5

Mfg Krampe


----------



## Ralle (26 Juni 2007)

Wir reden doch immer noch über Fehlersuche am Profibus und nicht über MPI, oder? Meinst du Stichleitungen in Kapitel 3.1.1 ? Das ist wieder eine andere Baustelle. Vladis Bemerkung betraf die DP-Baurate!

PS. Auch so, mein Link. Glaubst du das hab ich mit ausgedacht ?
Nein, das war aus einem Siemens-Handbuch. 

Aber wenn du es offizieller haben willst: http://www.sps-forum.de/showpost.php?p=61106&postcount=1


----------



## maggi.kochstudio (26 Juni 2007)

Hallo Olli.

Habe auch bei einer Anlage das gleiche Problem gehabt. Ne VB250 mit S7 modernisiert. Bei der Abnahme im Betrieb, wie auch beim Kunden die erste Zeit keine Probleme. Irgendwann fing es dann auch an mit den Problemen. Fehler OB's laden wollte ich nicht und bei nem Öffner für Extruder, Hydraulik etc. aus an ner dezentralen Eingangskarte wäre die Anlage eh ausgestiegen.
Nach langem hin und her und gesuche habe ich die PB-Leitung anders verlegt. Seitdem war Ruhe.
Also evtl. nen 50m Ring PB-Leitung mitnehmen, wenn das reicht bei Euren Riesenanlagen


----------



## dasding (26 Juni 2007)

Ralle schrieb:


> Wir reden doch immer noch über Fehlersuche am Profibus und nicht über MPI, oder? Meinst du Stichleitungen in Kapitel 3.1.1 ? Das ist wieder eine andere Baustelle. Vladis Bemerkung betraf die DP-Baurate!
> 
> PS. Auch so, mein Link. Glaubst du das hab ich mit ausgedacht ?
> Nein, das war aus einem Siemens-Handbuch.
> ...


 
  und wenn du jetzt mal deine Handbücher vergleichst dann siehst du das in dem einen bei 9,6 k/bits- 93,75 k/bits 1200m stehen und in dem von Siemens 1000m *g*, das meinte ich, und das von Siemens page sind die Aktuellen Normen. 
Aber er hat ja 1,5 und da sind beide gleich also passt es schon mit den 200m. Vladi hat sich bestimmt nur vertan mit den 50m bei 1,5.....

Aber olitheis schreibt auch das der Kunde einige Slaves ausgewechselt hat...hoffentlich sind diese kompatibel zu den alten gewesen, sonst könnte es auch daran liegen. Diagnosepuffer wär mal gut:-D 

Mfg Krampe


----------



## Ralle (26 Juni 2007)

dasding schrieb:


> und wenn du jetzt mal deine Handbücher vergleichst



Das überlaß ich glatt mal dir, bitte sehr!

Was soll der Scheiß, also wirklich!


----------



## crash (26 Juni 2007)

*Busfehler?*

Was steht im Diagnosepuffer der CPU ??? Dort kannst du sehen warum die CPU auf STOP geht bzw. welcher DP-Slave gestört ist.
Ich hatte auch mal ne Anlage die lange Zeit ohne Probleme lief.
Aber dann gabs immer wieder Störungen. Ab und an vielen immer irgendwelche DP-Slaves aus. Ich habe dann einen Diagnose-Repeater eingebaut und schwupps --> Fehler gefunden.
War ein defektes Buskabel (Kabelbruch Ader A) was zeitweise Reflektionen  aufm Bus verursacht hat. Der Diagnose-Repeater hat es sofort erkannt mit Angabe (in Meter) wo die Fehlerstelle ist. Allerdings ist bei den Dingern einiges zu Beachten was die Netztopologie angeht. Also *vorher* schlau machen.
Achja und *nicht-Siemens-Slaves *werden leider nicht richtig erkannt oder können nicht zugeordnet werden (war bei mir zumindest so --> SEW-FUs).


----------



## olitheis (27 Juni 2007)

Hallo,
nochmal kurz die Frage:
Wie kann ich denn jetzt die Memory Card auf der CPU beschreiben (ohne PG)?
*Ram nach Rom* kopieren oder *Auf Memory Card speichern* (oder?)?
Danke
Oli


----------



## Ralle (27 Juni 2007)

olitheis schrieb:


> Hallo,
> nochmal kurz die Frage:
> Wie kann ich denn jetzt die Memory Card auf der CPU beschreiben (ohne PG)?
> *Ram nach Rom* kopieren oder *Auf Memory Card speichern* (oder?)?
> ...



Ich mach immer "RAM nach ROM kopieren", um die aktuellen Daten zu sichern. 
Aber auch das ist von der CPU abhängig.
"Auf Memory Card speichern" ergibt bei mir die Meldung:
"Die Projektdaten können nur auf eine Memory Card im PG für die S7 400 oder auf die Memory Card in einer S7 400 CPU gespeichert werden."
Was wohl gleichzeitig besagt, daß die gesamten Projektdateien auf der Memory Card landen, wobei ich keine CPU 400 zur Verfügung hab.

Sieh auch mal hier: http://www.sps-forum.de/showpost.php?p=81906&postcount=15


----------



## vladi (27 Juni 2007)

*DP Störungen*

Hi,
betr. Diskussion über Baudraten und Längen: die max Längen von
Siemens beziehen sich auf opt. Bedingungen. Daher: 
die DB Baudrate runterfahren ist immer eine Probe wert, es bewirkt oft Wunder! 
Solche Fehler sicher zu lokalisieren: vergessene Sache. Teure SPS
bzw. Bus Analysatoren, Langzeitaufzeichnungen usw.: wer
macht das schon?

Deshalb mein Vorschlag:
1) Busleitungen/Stecker checken; evtl. neu verlegen(EMV Störungen?)
2) Baudrate reduzieren
3) Durch Diag. Bausteine versuchen, Fehler-Infos zu bekommen.

Viel Erfolg: Vladi


----------



## olitheis (27 Juni 2007)

@vladi
was meinst Du, wie Weit ich runtergehen kann?
Also die CPU steht ja auf 187.5kbit/s (MPI)
Die DP-Slaves auf 1.5Mbit/s (nächste Stufe wäre 500kbit/s).
Ich denke Du redest nur von den Slaves, richtig? Und dann alle gleich?

Danke
Oli


----------



## dasding (27 Juni 2007)

olitheis schrieb:


> @vladi
> was meinst Du, wie Weit ich runtergehen kann?
> Also die CPU steht ja auf 187.5kbit/s (MPI)
> Die DP-Slaves auf 1.5Mbit/s (nächste Stufe wäre 500kbit/s).
> ...


 
Hi
also ich check das grad nicht ganz....hast die CPU auf MPI mit 187,5 stehen und die Slaves hängen da dran mit 1,5? 
Also so geht das net falls das wirklich so ist, weil es müssen alle Teilnehmer die selben Busparameter haben. Und das haben sie auch wenn die am Mastersystem der CPU hängen. Lad doch nochmal deine Konfig hoch damit man sich das nochmal ansehen kann 
Schon mal schönen Feierabend  

Mfg dasding


----------



## da_kine (27 Juni 2007)

Wie sieht es denn mit den Busabschlüssen in den Teilnehmern aus?

Wir hatten mal ein ähnliches Problem, damals mit SEW Movidrive MD 60_A's. Die hatten auf den Profibus-Karten nochmal extra Abschlusswiderstände. Irgendwer, der es besonders gut gemeint hat, hat dann bei den Umrichtern die am Strangende waren die Abschlusswiderstände aufgeschaltet, aber nicht beachtet, dass der Bus schon im Stecker abgeschlossen wurde.

Der Fehler trat wie in deinem Fall mal Tagelang nicht auf und plötzlich 5 mal hintereinander usw. (Geisterfehler).

MFG

Markus


----------



## vladi (27 Juni 2007)

*Dp/mpi*

Moooooment, so gehts nicht!



olitheis schrieb:


> @vladi
> was meinst Du, wie Weit ich runtergehen kann?
> Also die CPU steht ja auf 187.5kbit/s (MPI)
> Die DP-Slaves auf 1.5Mbit/s (nächste Stufe wäre 500kbit/s).
> ...


 
MPI und DP sind zwei verschiedene Bus Systeme an der SPS. Die MPI Seite
ist klar: da kann man VISU, OPs, andere SPSen ansprechen. Die Baudrate ist da immer 187.5, das ist Siemens speziall Bus. An MPI gibt es kein
Master und Slaves in diesem Sinne.

Die DP Seite ist Master-Slaves Aufbau, ALLE fahren mit der gleichen
Baudrate(ob 1,5Mbit/s oder 93,75kbit/s, egal). Normalerweise wird bei
moderne Slaves keine Busrate mehr eingetragen, nur die eindeutige DP
Adresse(DIP Schalter, elektronisch). Der Master initialisiert alle beim
Start, er sagt "Freunde, sie sind jetzt bei mir angemeldet, wir fahren schön jetzt mit 500 kbit/s, aufpassen und kein Sch..s bauen!". Und dann sprechen sie miteinander.
Das bedeutet: die Baudrate im HW Konfig ändern, speichern, SPS laden, und dann wäre die Sache fertig! Der Master initialisiert dann sein Bus.
Wenn als Slaves noch SPSen dran hängen, muss man entspr. die Konfig's
ändern und auch alle neu laden, wegen der neuen Baudrate.

Gruss: Vladi


----------



## olitheis (27 Juni 2007)

@dasding
bitte schau mal weiter vorne, da habe ich die HW konfig mal hochgeladen. Sag mir bescheid, wenn Du damit nichts anfangen kannst.

@vladi


> Das bedeutet: die Baudrate im HW Konfig ändern, speichern, SPS laden, und dann wäre die Sache fertig! Der Master initialisiert dann sein Bus.


´
Du meinst also, am besten alle Slaves auf durchweg auf 500kbit/s im HW Konfig. runterschrauben? 

Noch eine Frage, wie initialisiert denn der Master den Bus, wenn verschiedene baudraten bei den Slaves eingestellt wurden im HW Konfig?
Vielen Dank
Oli


----------



## Ralle (27 Juni 2007)

olitheis schrieb:


> Noch eine Frage, wie initialisiert denn der Master den Bus, wenn verschiedene baudraten bei den Slaves eingestellt wurden im HW Konfig?
> Vielen Dank
> Oli



Wo stellst du denn die unterschiedlichen Baudraten bei den Slaves ein? So wie ich das verstehe, gibt es Slavebaugruppen, denen man die Baudrate in einem Setup einstellen muß (etliche OP/TP) und es gibt Slavebaugruppen, die die Baudrate selbst ermitteln (Indramatservos mit Profibus, Festo-Ventilblöcke etc.).  Die meißten  Slavebaugruppen  passen sich der Baudrate an, i.d.R. allerdings erst bei Zuschalten der Spannung, also Baudrate ändern in der CPU, Hardwareconfig übertragen und danach Spannung aus und wieder an.


----------



## dasding (28 Juni 2007)

olitheis schrieb:


> @dasding
> bitte schau mal weiter vorne, da habe ich die HW konfig mal hochgeladen. Sag mir bescheid, wenn Du damit nichts anfangen kannst.


 
Ja hab ich mir schon angeschaut... ist bloß doof das ich die GSD Dateien nicht habe, dadurch hab ich eventuell nicht alle parametriemöglichkeiten an den Slaves, aber wenn ich mir das ansehe was bei mir geht, dann steht dein Master (315-2DP) auf 1,5Mbits und deine Slaves hängen dort dran und haben auch 1,5 Mbits-> also so sieht alles in Ordnung aus. 
Wenn nun noch die Leitungen richtig verlegt sind und die Widerstände richtig eingeschalten sind, länge nicht überschritten wird und sonst nichts anderes bei den Slaves zu beachten ist(kenn die nicht) dann sollte es eigentlich laufen,aber wie gesagt eigentlich:-D 
Was war das mit der Geschichte, das dein Kunde einige Slaves ausgetauscht hat? Sind diese Kompatibel zu den alten gewesen?

Mfg dasding


----------



## vladi (28 Juni 2007)

*DP nochmals!*

Hi Oli,



olitheis schrieb:


> @vladi
> Du meinst also, am besten alle Slaves auf durchweg auf 500kbit/s im HW Konfig. runterschrauben?
> Noch eine Frage, wie initialisiert denn der Master den Bus, wenn verschiedene baudraten bei den Slaves eingestellt wurden im HW Konfig?


 
nochmals, kannst Du das nicht verstehen: Der DP Master initialisiert sein
DP Bus selber. Wenn Du in HW Konfig eine Baudrate einstellst, gilt die für alle! So, und wie die Slaves die Baudrate wissen, da gibt es 2 Mögl.:
1) pasive Slaves, die werden durch den Master eingestellt; man braucht da nur die DP Adresse manuell einstellen.(FUs, V-Inseln, IO Klemmen usw.)
2) aktive Slaves, wie SPSen, OPs usw. Da muss man ausser die Adresse 
die Baudrate und evtl. andere Sachen einstellen, und diese neu laden.

In deinem Fall sind die Slaves die 1) Sorte.

Gruss: Vladi


----------



## TommyG (29 Juni 2007)

Was

Lustiges, was vlt hilft:

Ne 'Nase' hat die Leitung FU- Motor ungeschirmt und mit dem Profibuskabel umgarnt in den Kanal geschmissen, mit ner Bypass- Leitung haben wir den Fehöler gefunden, ok, läüft und ich bin mal gespannt, was der 'Faul- ling' ausgibt..

Grrretz


----------



## olitheis (2 Juli 2007)

Hallo,
wie gesagt, letzte Woche war ich nun beim Kunden. Habe die Programmänderungen mit den Diagnose OB's, FB's usw. wieder übertragen. Während meines Aufenthaltes sind 3 Busknoten (Adr. 7,11,12) unabhängig voneinander ausgestiegen (die aber alle an einem Strang hängen, siehe Profibus Topologie im Anhang). Daraufhin habe ich alle Profibus Leitungen, die diese Slaves betreffen, so gut es ging aus den Kanälen gezogen und (erstmal provisorisch) außerhalb verlegt. Wie sich nachher herausstellte vergebens. Denn trotzden stieg immer wieder ein Slave aus (Antriebe, Adresse 7).
Dann habe ich die Badrate auf 500kbit/s runtergesetzt. Leider auch ohne Erfolg, immer noch der Slave mit Adresse 7 machte Probleme. Die Fehlermeldung laut Wago Handbuch: _"Klemmenbus-Kommunikation gestört, fehlerhafte Baugruppe ist nicht identifizierbar". _Laut Kundenangaben wurde dieser Slave schon mehrmals ausgetauscht, woraufhin ich die Slaves im HW Katalog nocheinmal begutachtet habe. Die projektierten waren alle 750-323 FW 01. Allerdings könnte es sein, das neuere auch eine neuere FW haben, und so habe ich alle Koppler in der HW Konfig ausgetauscht gegen 750-323 FW01...06, in der Hoffnung, dass der Hase im Pfeffer hier sitzt. Jetzt habe ich gerade einen Anruf bekommen, dass wiedermal der Profibus ausgestiegen ist, und zwar wiedermal Slave Adresse 7!?! Per TS habe ich nun so viele Infos wie möglich rausgezogen. Ich hoffe, ihr könnt mir hier noch etwas weiterhelfen.
Nochmals Vielen Dank
Oli


----------



## dasding (2 Juli 2007)

Ohh oh jetzt wirds schwer:???: also wenn du jetzt nicht schon geschrieben hättest das der Slave schon öffters ausgetauscht wurde-> hät ich das jetzt vorgeschlagen, sieht ganz stark nach nen Hardware defekt aus.
Leitungen hast du auch gecheckt, also sind die es auch nicht, Leitungslänge kann es auch nicht sein, da Teilnehmer 7 nicht der letzte am Bus ist und die danach noch gehen und Firmware sollte eigentlich in der Projektierung egal sein, solange wie der Slave eine höhere hat wie die Projektierte, aber die sind auch gleich -> also um so besser.
Aber es geht immer noch net, bin grad ratlos und kenn den FB 125 net, bessergesagt hab den noch nie benutzt:???: 
Aber es war jetzt kein Bild von der DP-Slave Diagnose dabei(vom WAGO) *schade* vielleicht wär da noch was nützliches bei gewesen-> weil CPU sagt ja nicht viel aus in deinem fall.
Handelte es sich jetzt um einen Neubau? oder eine bestehende Anlage?
Fällt mir jetzt erst mal nur noch EMV Störung ein, solch einen fall hatte ich mal, dort war auch der vorletzte Teilnehmer immer ausgefallen-> lag im endefekt an den 50 Motorleitungen die direkt neben der Busleitung verlegt wurden und frag nicht warum nur der Vorletzte ausgefallen war, versteh ich auch net*g*

Mfg dasding


----------



## da_kine (2 Juli 2007)

Wurde die Komplette Station 7 ausgetauscht, oder nur der Busankoppler? Weil die Diagnose sagt ja "Klemmenbus defekt". Daher die Vermutung, das die Verbindung der Klemmen untereinander irgendwo schadhaft ist.

MFG

Markus


----------



## olitheis (2 Juli 2007)

@dasding
wenn Du Dir das Bild mit Profibus Topologie ansiehst, dann habe ich von Station 9->11 alle Profibusleitungen herausgezogen. Von 11->12 das habe ich drin gelassen (aber auch dort liegen Motorleitungen). Ich dachte nur, da eigentlich Station 7 nur noch Probleme macht, das wäre nicht notwendig.

@da_kine
ne, die komplette Station wurde noch nicht gewechselt. Ich hatte mich bis dato ja auch noch nicht wirklich auf eine Station festgelegt. Das diese jetzt nur noch alleine aussteigt, ist noch nicht immer so gewesen. 

Ach ja, die Metallfolie im Kabel ist abgeschnitten worden (s. Foto). Sollte die mit aufgelegt werden, und wie wäre das dann (korrekt) zu handhaben?

Gruß
Oli


----------



## da_kine (2 Juli 2007)

Metallfolie im Kabel??

Der Schirm is doch aufgelegt. Da is doch keine Metallfolie drin, sondern nur noch diese Plastikfolie. Oder?

Hast du schon mal mit den Wago-Leuten geredet, ob es Modul-Kombinationen gibt die sich nicht vertragen? Hatte sowas mal mit nem anderen Hersteller. Als wir dann die Reihenfolge der Klemmen geändert hatten lief es einwandfrei.

MFG

Markus


----------



## olitheis (2 Juli 2007)

diese Folie meinte ich.
Hatte gerade mit Wago kontakt. Er meinte halt zu diesem Fehlercode, dass der Koppler die Klemmen nicht erkennt (keine). Diese deute auf einen defekten Koppler hin oder einen Kurzschluß auf dem Komm. Bus. Er schlägt vor, den kompletten Knoten zu tauschen. Mich macht nur stutzig, dass auch schon andere Koppler ausgestiegen sind (sollten die alle def. sein? davon habe ich leider keine Fehlercodes).

Oli


----------



## dasding (2 Juli 2007)

Ja das ist schon so eine Art Alupapier, kann man mit Auflegen ist eigentlich auch besser um eine bessere Schirmung zu erhalten aber kenne jetzt selber keinen Fall wo mit Folie oder ohne eine Änderung erreicht wurde:-D 

Mfg dasding


----------



## da_kine (2 Juli 2007)

Denke, dass du es dir sparen kannst, die Folie aufzulegen, da sie ja flächigen Kontakt mit dem restlichen Schirm hat.

Währe halt interessant zu wissen ob die Rückwandbusklemmen alle aus einer Produktionscharge stammen. vllt. lässt sich das Problem so eingrenzen. 

MFG

Markus


----------



## olitheis (2 Juli 2007)

ich habe gerade noch eine e-mail an den support von Wago geschickt, bez. der von Dir erwähnten Klemmenreihenfolge. Irgendwo war da mal was mit vollzusteckenden Bytes usw. Die HW Konfig sieht so aus wie auf dem 1. Bild.
Wirklich gesteckt sind folgende:
1x 750-323 (Koppler)
7x 750-403 (4x DI's)
4x 750-411 (2x DI'S)
1x 750-602 (Power Supply)
8x 750-504 (4x DI's)
1x 750-600 (End Module)

Könnte es evtl. hier ein Problem sein, dass ich im 4. Eingangsbyte 403er und 411 Module gemischt habe und das letzte Byte nicht voll gesteckt ist?
Auf dem 2. Bild sieht man die Installation den Knotens.

Gruß
Oli


----------



## da_kine (2 Juli 2007)

olitheis schrieb:


> 7x 750-403 (4x DI's)
> 4x 750-411 (2x DI'S)



Wenn ich das richtig verstanden habe, gibt das 36 gesteckte zu 40 Projektierten. Das könnte schon ein Problem sein, denke ich. Warum hast du nicht den wirklichen Bestand in die HW-Config eingetragen? 

Und für den Schaltschrank hat der Lehrling doch hoffentlich auf die Mütze bekommen...


----------



## Onkel Dagobert (2 Juli 2007)

Hallo Oli,

so wie es aussieht, ist es ein ähnlicher Fehler, wie ich ihn weiter oben versucht habe, zu beschreiben.



Onkel Dagobert schrieb:


> ..Nach Abtrennen aller Slaves eines bestimmten Typs trat der Fehler nicht mehr auf. Ich vermute, die Schutzbeschaltung am Busanschluss dieser Teilnehmer war etwas übersensibel oder ganz falsch ausgelegt...


Ich denke, jedes Businterface ist mit einer Schutzbeschaltung gegen Überspannung auf der Busleitung geschützt. Das könnten z.Bsp. Zenerdioden sein, die gegen Masse und Spannungsversorgung geschaltet sind. Wenn nun eine kurze Spannungsspitze auftritt, wird diese i.d.R. nach Masse abgeleitet, was einem kurzzeitigen Massekurzschluss einer Busleitung gleich kommt. In unserem Fall entstand durch gleichzeitiges Schalten mehrerer Gleichspannungsschütze eine Spannungsspitze auf der 24V-Versorgung. Durch diese Spannungsspitze fühlte sich ein bestimmter Typ von Busteilnehmer dazu veranlasst, besagtes Verhalten aus zu lösen. So habe ich mir das damals erklärt, ob's nun technisch korrekt ist, möchte ich nicht behaupten. Die Ursache (Schützschalten/bestimmter Busteilnehmer-Typ) stand jedoch eindeutig fest. Erst als alle Busteilnehmer dieses Typs (es waren sieben oder acht) vom Bus genommen wurden, lief er stabil. Sobald nur ein einziger am Bus hing, trat der Fehler wieder auf.

Der durch Diagnose als ausgefallener Busteilnehmer gemeldete, war immer rein zufällig ein anderer. Vermutlich der (unschuldige), der gerade vom Busmaster angesprochen wurde. Das widerspricht einem Vergleich mit deinem Fall etwas, da es bei dir meist die selben sind. 

Wir hatten damals den Bus bilderbuchmäßig komplett neu verlegt. Stahlpanzerrohre, Potenzialausgleich, Busstecker gewechselt, großflächige Schirmung bei Ein- und Austritt aus Schränken und Klemmkästen. Nichts hatte geholfen!

Motorleitungen (50Hz) stören den Bus eigentlich nicht. Was wirklich tötlich ist, sind Transienten auf Gleichspannungsleitungen.

Überprüfe doch mal, ob Gleichspannungsschütze, Relais etc. in der Umgebung der gestörten Teilnehmer geschaltet werden. Selbst mit Schutzbeschaltung sind noch deutliche Spannungsspitzen zu messen (Oszi, Multimeter mit Peak-Messung reicht auch schon).

Buskoppler, die als gestört gemeldet werden, vielleicht mal gegen andere, die weniger betroffen sind, austauschen.


Gruß, Onkel


----------



## Onkel Dagobert (2 Juli 2007)

Hab' gerade noch was gefunden.



olitheis schrieb:


> ..Ach ja, die Metallfolie im Kabel ist abgeschnitten worden (s. Foto). Sollte die mit aufgelegt werden, und wie wäre das dann (korrekt) zu handhaben?..


 


			
				PROFIBUS-Netze SIMATIC NET 6GK1970–5CA20–0AA0 schrieb:
			
		

> Kontaktieren Sie SIMATIC NET PROFIBUS–Leitungen nur über den Kupfergeflechtschirm, nicht über den Al–Folienschirm. Der Folienschirm ist zur Erhöhung der Reißfestigkeit einseitig auf eine Kunststoffolie aufgebracht und damit nichtleitend!


 

Gruß, Onkel​


----------



## Syntaxfehler (2 Juli 2007)

Hallo,

wir haben auch diese Wago Module. Schau doch mal auf das Datenblatt 705-403 und 411er. Nur die 750-411 Serie kann man mit Näherungsinitiatoren betreiben.
Kann es daher sein, das vielleicht mit einer falsch gesteckten Karte, die dann bei einen Schaltimpuls eines Initiators diesen Fehler hervorheben kann? Daher tritt er auch später auf und nicht sofort, weil irgendetwas schaltet.

Gruß Syny


----------



## dasding (3 Juli 2007)

Onkel Dagobert schrieb:


> Hab' gerade noch was gefunden.
> 
> Zitat von *PROFIBUS-Netze SIMATIC NET 6GK1970–5CA20–0AA0*
> _Kontaktieren Sie SIMATIC NET PROFIBUS–Leitungen nur über den Kupfergeflechtschirm, nicht über den Al–Folienschirm. Der Folienschirm ist zur Erhöhung der Reißfestigkeit einseitig auf eine Kunststoffolie aufgebracht und damit nichtleitend!_
> ...


 

Das kannte ich so noch nicht zählt doch aber nur wenn man alles nach hinten "Krempelt" oder? Wenn man nur abisoliert und auflegt ist es ja egal,oder?

Mfg dasding


----------



## olitheis (3 Juli 2007)

@da_kine


> Wenn ich das richtig verstanden habe, gibt das 36 gesteckte zu 40 Projektierten. Das könnte schon ein Problem sein, denke ich. Warum hast du nicht den wirklichen Bestand in die HW-Config eingetragen?


man kann in der HW Konfig. für die 323er Koppler die Klemmen nur byteweise konfigurieren. Ich müsste also, damit es paßt, immer die Klemmen hardwaremäßig ergänzen. 

@Syntaxfehler
wie handhabt ihr denn so etwas? Steckt ihr immer volle Bytes? Ich weiß, dass das bei verschiedenen Kopplern notwendig ist. Auch bei diesen?
Ich habe den Schaltplan nochmal durchgesehen: es werden eigentlich nur Schließer- oder Öffnerkontakte eingelesen, keine Ini's.

@Onkel Dagobert
Ausgangsseitig werden von dem (ich sage mal zuletzt öffter) betroffenen Busknoten "nur" 24Vdc Finder Koppelrelais, 24Vdc Moeller LED's und ein Ventil geschaltet. Der Fehler trat aber auch schon mal auf, als nur die Anlage mit "Hydraulik Ein" gelaufen war, also keiner _*dieser*_ Ausgänge hatte ein- oder ausgeschaltet zu der Zeit (denke ich?).
Wir habe auch für die Buskopplerversorgung und die I/O-Ebene zwei separate Netzteile verwendet.
Soweit ich das überblicken konnte, durfte eigentlich im Fehlerzeitpunkt nur eines der 3 Ladeventile der Hydraulik Kolbenspeicher ein- oder ausgeschaltet haben (Hydraulilk Ein->Speicher werden ständig nach bedarf geladen). Aber die Ladeventile (ca. 1,25A) werden von Slave 10 und 12 (siehe Topologie) angesteuert. Der (momentane) "Problemslave" hängt dazwischen.

Vielen Dank
Oli


----------



## olitheis (3 Juli 2007)

ich muss die Angaben über die Module nocheinmal korrigieren. Habe gerade den genauen Aufbau des Knotens vom Kunden bekommen:


> 7x Wago 750-403
> 4x Wago 750-*401*
> 1x Wago 750-602
> 8x Wago 750-504 one of them is free (whithout wires)
> 1x Wago 750-600 this is free


----------



## Onkel Dagobert (3 Juli 2007)

Hall Oli,



olitheis schrieb:


> ..Soweit ich das überblicken konnte, durfte eigentlich im Fehlerzeitpunkt nur eines der 3 Ladeventile der Hydraulik Kolbenspeicher ein- oder ausgeschaltet haben (Hydraulilk Ein->Speicher werden ständig nach bedarf geladen). Aber die Ladeventile (ca. 1,25A) werden von Slave 10 und 12 (siehe Topologie) angesteuert. Der (momentane) "Problemslave" hängt dazwischen...Oli


Sind das DC-Ventile? Den Dingern würde ich unbedingt mal auf den Zahn fühlen, Freilaufdiode (meist im Stecker) überprüfen und Spannungsspitzen beim Schalten messen. Die entsprechenden DC-Kabel (auch die Zuleitung) weit weg von dem Buskabel verlegen.


Gruß, Onkel


----------



## olitheis (3 Juli 2007)

Hallo Onkel,

wir verwenden immer 24Vdc Magnetspulen, ca. 100 St. verteilt über die ganze Anlage.
Meinst Du, dass evtl eine Spule oder ein Anschlußstecker ein Problem macht?

Gruß
Oli


----------



## o.s.t. (3 Juli 2007)

@oli,

wir verwenden auch schon seit 7-8 Jahren erfolgreich die Wago 750er I/O Serie.

hie und da hatten wir auch (vorerst nicht reproduzierbare) Störungen auf einzelnen Stationen. Das Problem war der interne Klemmenbus zwischen den Modulen, da waren wohl einige Kontakte oxidiert. Auf die Schliche kommt man, wenn man die ganze Station mit beiden Händen packt und dann in sich leicht verdreht/verwindet. Wenn dann auf dem Buskoppler die LEDs Disco machen, dann hat man DIE Station gefunden! 
Als (vorübergehender) Workaround kann man folgendes machen: jedes einzelne Modul 2-3 mal leicht rausziehen und wieder reinschieben, dabei reinigen sich die Kontakte des Klemmenbusses. Entweder es läuft jetzt ewig oder nach einigen Monaten tritt der Fehler vielleicht wieder auf. Haben beides schon erlebt.

Vielleicht hilft dieser Tip !
gruss, o.s.t.


----------



## maddin (3 Juli 2007)

@ oli,



> man kann in der HW Konfig. für die 323er Koppler die Klemmen nur byteweise konfigurieren. Ich müsste also, damit es paßt, immer die Klemmen hardwaremäßig ergänzen.


 
wie verwenden zum Teil auch Wago Module, wenn wie in deinem Falle das letzte Byte nur zur Hälfte bestückt ist, so hat dies keine Auswirkungen.
Bei uns wurde dies an mehreren Stationen so praktiziert (sparen, sparen  ).

Läuft deine Profibusleitung durch irgendwelche Kabelschleppe (Energieketten)??. Ich hatte mal einen Kabelbruch in einem Kabelschlepp, der eigentlich keine allzu großen und häufigen Bewegungen machte, leider hatte so ein helles Köpfchen keine schleppfähige PB-Leitung verwendet, sondern die Leitung mit den massiven Adern.
Der Kabelbruch bewirkte immer eine einmalige Unterbrechung des Busses, und zwar so ca. alle 5-6 Tage einmal... :sb9: 

Zitat von o.s.t.


> hie und da hatten wir auch (vorerst nicht reproduzierbare) Störungen auf einzelnen Stationen


 
kann ich nur bestätigen... Allerdings war es bei uns keine Oxidschicht, sondern Haarrisse in der Goldlegierung der Kontakte für den internen Bus.
Das ist aber schon viele Jahre her. Die Module wurden alle von Wago eingezogen und ersetzt. Fehleranalyse exakt nach der Beschreibung von O.S.T.  


Bis dann

Gruß maddin


----------



## olitheis (4 Juli 2007)

@o.s.t
danke für den Tip!
Da der Kunde ja in Spanien ist und ich nicht vor Ort bin, ist das erstmal eine sehr gute Maßnahme. 

@maddin
ich habe mir hier den gleichen Busknoten mal aufgebaut, er läuft einwandfrei wie er ist (war ja eigentlich auch zu erwarten, aber z. Zt. greife ich halt jeden Strohalm;-))
Wie lange ist denn das her, mit den Haarrissen? Vielleicht haben wir ja auch Module aus dieser Charge erwischt (Anlage ist von 1999/2000).

Noch eine Frage: Ich habe gesehen, es gibt von Deltalogic diesen 15PB-T3 Profibus Kabeltester (Expresslink 0755). Hat jemand schonmal mit so einem Gerät gearbeitet? Lohnt sich so etwas?

Vielen Dank nochmal an Alle
Oli


----------



## Ralle (4 Juli 2007)

olitheis schrieb:


> Noch eine Frage: Ich habe gesehen, es gibt von Deltalogic diesen 15PB-T3 Profibus Kabeltester (Expresslink 0755). Hat jemand schonmal mit so einem Gerät gearbeitet? Lohnt sich so etwas?
> 
> Vielen Dank nochmal an Alle
> Oli



Wir nutzen den Profibustester und er leistet bei der Fehlersuche, vor allem aber bei der Beurteilung der Qualität des Profibusses gute Dienste. Nach dem Einrichten des Busses, mache ich damit immer nochmal eine Bestandsaufnahme.
So kann man später auch abschätzen, ob die Busqualität (Spannungspegel, Flankensteilheit) schlechter geworden ist. Auch bei der Eingrenzung der Störstelle kann er helfen. Allerdings ist auch mit Profibustester in erster Linie Erfahrung und das richtige Händchen gefragt, denn zaubern oder wahrsagen kann er leider auch nicht.
Bei sporadisch auftretenden Fehlern, die vielleicht noch mit Firmwareproblemen zu tun haben, wird der PBT auch nicht unbedingt weiterhelfen.


----------



## olitheis (7 Juli 2007)

*und schon wieder*

Hallo,
habe heute wiedermal mit dem Kunden gesprochen. er hat gesagt, dass der besagte Knoten 7 schon 2 mal in der letzten Woche ausgestiegen war. Aber der eigentliche Grund seines Anrufs war, dass ein anderer Busknoten (15) ausgestiegen war. Er war gerade dabei den Koppler zu tauschen. Ich habe ihm auch nocheinmal die Sache mit dem "Klemmenziehen" beschrieben (zum reinigen). 
Ich habe euch mal einige Infos hochgeladen, vielleicht hat ja nun jemand eine idee? Ich habe zwar den FB 125 programmiert, allerdings hilft em mir nicht wirklich mehr. Wie kann ich ihn denn am sinnvollsten einsetzten?

Ich spiele jetzt ernsthaft mit dem Gedanken, den deltalogic PB-T3 anzuschaffen.

Vielen Dank noch einmal
Oli


----------



## AndreK (7 Juli 2007)

*Mir ist mit Profibus mal folgendes passiert...*

Die alte Anlage lief mit einer S5 115U und IM308-B sb5 Die Anlage wurde dann von mir mit einer 315DP2 umgerüstet. Die S5 ET200U blieben bestehen. Erst mit der S7 gab es Probleme mit einem Teilnehmer der sporadisch ausstieg. Konnte alle 2 Stunden oder auch nur einmal in 2 Wochen passieren.
Das Ende vom Lied: Habe mal ein olles 10Mhz Ozzi auf die 24V Versorgungsspannung gelegt. Dort konnte ich dann hin und wieder starke Peaks erkennen. Nachdem ich erkannt hatte das es alte Siemensschütze von Drehstromrüttlern (230V) waren habe ich diese mit gerade greifbaren RCGliedern entstört. Seit dem ist Ruhe...
Will damt nur sagen: Das Problem muß ja nicht an deinem Netz liegen, können ja auch Störquellen von außen sein...


----------



## Onkel Dagobert (7 Juli 2007)

*Spannungsspitzen*

Hallo Oli,



AndreK schrieb:


> ...Habe mal ein olles 10Mhz Ozzi auf die 24V Versorgungsspannung gelegt. Dort konnte ich dann hin und wieder starke Peaks erkennen...


Darauf setze ich einen Kasten Wernesgrüner  .


Gruß, Onkel


----------



## MeTh (7 Juli 2007)

*Defekte Hardwaretreiber an Profibusteilnehmern*

Hallo,

wir hatten neulich auch den Fall, dass sich ein Profibus mit 9 Teilnehmern
(4x S7 300, 1x S5 IM308, 4x Sick Scanner + Profibusmodul) immer wieder aufgehängt hat (Stop).

Wir haben dann einen Fachmann eingeladen.
http://www.hlg.homepage.t-online.de/
Dieser Mann hat mit seinen Meßgeräten defekte Treiber (Hardwaretreiber, die zutändig sind für den Profibus) festgestellt. Die defekten Treiber ziehen die Spannung des Profibus (ist ja ein Spannungsbus) runter.
Grund dafür ist, dass der Schirm des Profibuskabels, der ja beidseitig aufgelegt ist, eine zu hohe Spannung führt (Statische Aufladung in einem Kunststoffunternehmen).

Wir haben dann die Aufgabe bekommen, alle Profibusteilnehmer mit einem Parallel zum Bus verlegten 16mm² PA alle Schirme zu Verbinden und zu Erden.

Als nächstes müssen dann die Teilnehmer mit defektem Treiber getauscht werden. Dannach wird eine weitere Messung gestartet, die die Qualität des Profibusses festhält.

Der Mann ist richtig gut auf seinem Gebiet und ist Europaweit im Einsatz
(hat aber auch seinen Preis).

Ist das Busmodul Örtlich etwas weiter weg, wie die anderen?
Man könnte (sollte das bei deiner Anlage auch der Fehler sein) auch einen
Repeater setzten. Der würde die Spannung von dem Treiber mit Kurzschluss abkoppeln.

Vielleicht hilft der Beitrag.

Viel Erfolg beim Suchen weiterhin.
MeTh


----------

