Profibus Slave von CPU nicht erkannt, aber als erreichbarer Teilnehmer

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich war letzte Woche an einer Anlage mit einer S7-300 und 11 Profibusteilnehmern zu einer Fehlersuche. Leider konnte ich den Fehler vor Ort nicht beheben
Dort ist ein Anybus-Gateway am Profibus angeschlossen, welches ausgefallen war. Ich bin mit meinem PG online gegangen, CPU zeigt auch den Teilnehmer als nicht erreichbar an. Am Gateway wurde auch mit einer roten LED der Busfehler angezeigt. Ich habe mich dann mit meinem Profibusadapter an die PG-Buchse der CPU gehängt, Teilnehmer wird auch nicht gefunden.

Die Anlage ist nicht von uns erstellt worden, die Topologie sieht zumindest teilweise wie folgt aus:

<CPU>---<Repeater>---<10 Teilnehmer>---<Anybus-Gateway>---<Aktiver Abschlusswiderstand>

Am Repeater ist wohl noch eine Stichleitung, das habe ich nicht nachverfolgt.

Auf jeden Fall habe ich mit dann mit meinem PG direkt an das Anybus-Gateway angeschlossen (Profibus-Stecker ab), einziger Master am Bus eingestellt, und das Gerät wurde gefunden. Dann habe ich mich mit einem Zwischenkabel mit PG-Buchse zwischen Gerät und Busanschluss gesteckt. Erreichbare Teilnehmer zeigten nun alle Teilnehmer an, bis auf das Gateway. Schon einmal phänomenal.
Da mir nichts weiteres eingefallen ist, habe ich den Profibus-Stecker gegen ein wenn auch alten Stecker getauscht. Aber keine Besserung.

Dann habe ich das Anybus-Gateway mit einem fliegenden Profibuskabel direkt an die PG-Buchse an der CPU aufgesteckt. Ich habe mich mit meinem PG an den Anschluss des Repeaters angesteckt. Alle Teilnehmer werden gefunden, inklusive des Anybus-Gateways. Aber die CPU erkennt das Gerät weiterhin nicht.

Es gab vor Ort noch ein Ersatzgerät dieses Gateways, das habe ich auch getauscht. Macht keinen Unterschied.

Vor Ort dann erstmal diese Aufgabe abgebrochen, und das Ersatzgerät mit ins Büro genommen. Testprojekt erstellt, den Profibus-Slave 1:1 aus dem Quellprojekt kopiert und in mein Testprojekt eingefügt. CPU geladen und gestartet, läuft. Zumindest der Slave wird erkannt, Datenkommunikation kann ich mangels Gerätes auf der anderen Seite des Gateways nicht testen, aber im ersten Schritt sollte zumindest der Slave vom Master gefunden werden.

Ich bin jetzt etwas mit meinen Ideen am Ende, warum das Gerät vor Ort von der CPU nicht erkannt wurde. Angeblich war das Gateway nach einem Netzausfall oder Netzwischer ausgefallen.

Ich weiß nicht, ob ich ein Busproblem ausschließen kann, wenn das erreichbare Teilnehmer funktioniert. Eventuell ist das nicht ganz so pingelig? Hat jemand noch eine Idee? CPU Online/Offline Vergleich zeigte keine Unterschiede bei den SDBs.

 

[DeltaMikeAir]

Aber die CPU erkennt das Gerät weiterhin nicht.

Was ist es denn für ein Gerät?

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Was ist es denn für ein Gerät?

Ein Anybus-Gateway von Profibus-DP auf serielle Kopplung (evtl. Modbus-RTU), ist nicht von mir parametriert.

 

[PN/DP]

Vielleicht ist an der Stelle des Gateways der RS485-Pegel zu gering oder es sind zu viele Störungen auf dem Profibus? Vielleicht sind zu viele Abschlußwiderstände eingeschaltet oder irgendein Teilnehmer belastet den Bus zu stark?

Harald

 

[Thomas_v2.1]

Vielleicht ist an der Stelle des Gateways der RS485-Pegel zu gering oder es sind zu viele Störungen auf dem Profibus? Vielleicht sind zu viele Abschlußwiderstände eingeschaltet?

Das wollte ich ja mit meinem fliegenden Anschluss auf die PG-Buchse der CPU ja ausschließen. Das macht die Terminierung zwar auch nicht besser, aber als erreichbarer Teilnehmer wurde das Gerät am Profibus von meinem PG an der PG-Buchse des Repeaters ja auch gefunden. Das macht es ja so verwirrend, warum das funktioniert, aber keine Kommunikation mit der CPU.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ist vielleicht ein weiterer Busteilnehmer mit der selben Profibus-Adresse vorhanden?

Das Anybus-Gateway hat doch bestimmt eine Firmware. Vielleicht gibt es eine neuere/verbesserte Firmware-Version.

Bei "Erreichbare Teilnehmer" oder irgendwie scannen des Busses wird vermutlich nur gecheckt, ob für eine Profibusadresse ein Gerät existiert. Für die Aufnahme der zyklischen Master-Slave-DP-Kommunikation muß zusätzlich die Profibus-Ident-Nummer des DP-Slaves mit der in HW Konfig projektierten Ident-Nummer übereinstimmen. Und der Slave muß die im Master projektierten Steckplätze/Slots akzeptieren - hat sich vielleicht irgendwas im Hardware-Aufbau des Gateways geändert (z.B. Defekt)?

Harald

 

[Thomas_v2.1]

Doppelte Adresse hatte ich auch in Verdacht, aber es hat sich bei abgezogenen Gerät keiner unter dieser Adresse gemeldet.

Die Firmware des Geräts hatte ich auch in Verdacht. Denn es wurde nach dem Ausfall zuerst der Hersteller des Geräts hinter dem Gateway kontaktiert, der war vor Ort und hat gesagt auf seiner Seite wäre alles in Ordnung und hat zum Test auch das Ersatzgerät des Gateways (gehört bei denen dazu) da gelassen. Denn da gibt es von HMS zwei GSD-Dateien für unterschiedliche Firmwareversionen. Das war dann meine Vermutung, dass jemand evtl. eine neue Firmware aufgespielt hat. Da ich vor Ort schlecht experimentieren kann mit CPU Stopp usw., habe ich das dann eben im Büro an einer Test-CPU gemacht, mit 1:1 dem Slave aus dem Quellprojekt, was dann funktioniert. Darum würde ich das ausschließen.

 

[Oberchefe]

Um welches Anybus Gerät geht es genau? Möglicherweise übernimmt es nach dem Einschalten die Baudrate automatisch vom Bus. Wenn du mit dem Laptop alleine an dem Gerät dran warst, dann hat es möglicherweise diese Baudrate genommen und deshalb mit der anderen an der CPU natürlich nicht mehr funktioniert (sofern diese anders war).

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das ist ein Anybus AB7000-C. Die Variante benötigt eigentlich eine andere GSD-Datei als im Projekt steht, aber evtl. ist das ja abwärtskompatibel. Außerdem hat es so die letzten 10 Jahre gelaufen, und der Test im Büro war damit auch erfolgreich.

Baudrate an meinem PG war genau gleich eingestellt 1,5 MBit/s und Standard. Mit meiner fliegenden Verkabelung konnte ich ja sogar alle Teilnehmer finden, da war ich nach Anschluss gar nicht mit dem PG dran. Außerdem habe ich da natürlich den Haken bei "einziger Master am Bus" herausgenommen, dann sollte die CPU ja den Takt vorgeben.

Was mir gerade noch einfällt, dass ich im Programm mal prüfen sollte, ob da warum auch immer nicht ein Slave vom Programm heraus deaktiviert wird. Da ich das selber noch nie verwendet habe, weiß ich nicht wie sich das dann in der Praxis darstellt. Eigentlich macht man das doch, damit auch die SF an der CPU ausgehen in dem Fall.

 

[DeltaMikeAir]

ob da warum auch immer nicht ein Slave vom Programm heraus deaktiviert wird.

Dann wird er in der HW Konfig in der Onlineansicht nicht als gestört angezeigt sondern "ausgegraut". Also kein rotes und kein schwarzes Symbol an der GSD-Datei ( Onlineansicht ) sondern grau.

Dann kommt auch kein BF/SF für diesen Teilnehmer.

Umgesetzt wird das mit dem SFC 12

 

[Thomas_v2.1]

Dann wird er in der HW Konfig in der Onlineansicht nicht als gestört angezeigt sondern "ausgegraut". Also kein rotes und kein schwarzes Symbol an der GSD-Datei ( Onlineansicht ) sondern grau.

Dann kommt auch kein BF/SF für diesen Teilnehmer.

Nein, das sah nicht anders aus als bei einem normalen ausgefallen Teilnehmer, SF/BF und in Hardware diagnostizieren Slave nicht erreichbar. Aber ich schaue zur Sicherheit nochmal nach ob ich da im Programm etwas finde.

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Nein, das sah nicht anders aus als bei einem normalen ausgefallen Teilnehmer, SF/BF und in Hardware diagnostizieren Slave nicht erreichbar.

Ja, dann wird da wohl nichts deaktiviert. Ich mache dir morgen mal einen Screenshot von deaktivierten Teilnehmern, dann hast du has auch mal gesehen.

 

[Lipperlandstern]

Ich kann mich an einen ähnlichen Fall erinnern. Nach CPU Stop - Run war alles wieder gut. Als wenn das Gerät irgendwas vergessen hat was beim Neustart wieder geladen wurde.

 

[Thomas_v2.1]

Stop/Run habe ich wirklich noch nicht gemacht, weil das nicht ganz einfach ist und gleich Geld kostet. Die Vermutung, dass die CPU vielleicht eine Konfiguration verloren hat, hatte ich auch schon. Aber davon habe ich noch nie was gehört gehabt bisher.

Aber ich sammel erstmal ein paar Ideen für den nächsten Einsatz, weil sonst habe ich aufgrund der Tests die ich bisher gemacht habe, nämlich keine Idee mehr. Profibus-Pegel messen würde auch noch auf dem Zettel stehen.

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Thomas_v2.1

hier wie versprochen ein paar Bilder zu deaktivierten Busteilnehmern:
Adr. 88 = deaktiviert ( oben links grau + Strich durch )
Adr. 89 = aktiv aber gestört
Adr. 90 = aktiv und störungsfrei


So sieht dann die Diagnose aus, wenn ein Teilnehmer deaktiviert ist:

 

[Lipperlandstern]

Stop/Run habe ich wirklich noch nicht gemacht, weil das nicht ganz einfach ist und gleich Geld kostet. Die Vermutung, dass die CPU vielleicht eine Konfiguration verloren hat, hatte ich auch schon. Aber davon habe ich noch nie was gehört gehabt bisher.

Aber ich sammel erstmal ein paar Ideen für den nächsten Einsatz, weil sonst habe ich aufgrund der Tests die ich bisher gemacht habe, nämlich keine Idee mehr. Profibus-Pegel messen würde auch noch auf dem Zettel stehen.

Ich hab das seinerzeit nicht weiter verfolgt da Run/Stop problemlos möglich war und der Fehler nicht wieder auftrat. Aber ich würde jetzt mal das Ersatzgerät einbauen. Wenn es so etwas wie eine "Taufe" von der CPU während des Startes der CPU gibt müsst das Ersatzgerät jetzt ja funktionieren.

Den Anybus-Adapter mal abgeklemmt und wieder angeklemmt hast du bestimmt gemacht .

 

[Hans-Ludwig]

Folgende Anregungspunkte:

• Bei manchen alten Baugruppen muss man die 24 VDC ab und anschalten damit die Baudrate bei einer FDL Statusabfrage angenommen wird. Man legt sich damit oft Fallstricke.
• An der Baugruppe AB7000-C ist der Schirm nicht geerdet. Dass könnte zur Schädigung der Treiber geführt haben. Das gilt auch für die SPS. (Da ist möglicherweise die EMV am höchsten) Die ist, wenn ich es richtig verstanden habe, auf der DP Schnittstelle schwerhörig für das Gerät AB7000-C, nicht für das PG, oder das AB7000-C selber ist scherhörig.
• Manche Baugruppen konnte man nicht hinter einem Repeater betreiben. VPC 3
• Stichleitung? Beim Versuch mit dem Zwischenkabel.
• Die Buchse auf dem Repeater geht in Richtung SPS und könnte damit auch ein Stich sein?
• Wenn man was verändert, und es ändert sich das Fehlerbild, so ist man ganz nahe dran. Es scheint dass es ein Hardwareproblem ist.
• Wenn Du die Baudrate auf 500kBit reduzierst und der Bus läuft, ist es ein Hardwareproblem.

 

[rlw]

Zuviel Werbung?
-> Hier kostenlos registrieren

Jetzt komme ich wieder : Solche Probleme löst man mit einem Profibus-Analyzer.

 

[JesperMP]

Dann habe ich das Anybus-Gateway mit einem fliegenden Profibuskabel direkt an die PG-Buchse an der CPU aufgesteckt. Ich habe mich mit meinem PG an den Anschluss des Repeaters angesteckt. Alle Teilnehmer werden gefunden, inklusive des Anybus-Gateways. Aber die CPU erkennt das Gerät weiterhin nicht.

Ist dies noch die letzte Stand vor-ort ?
Ich kenne die Anybus Gateway nicht, aber vielleicht funktioniert es fast wie ein DP/DP Koppler.
Vielleicht liegt die Fehler bei die Partner auf die andere Seie von die Gateway. Wenn ein DP/DP Koppler auf die gegenseite nicht von ein Partner angesprochen wird genau wie es in das STEP7 Projekt konfiguriert ist, dann erzeugt es auch ein BF auf die Seite welche nicht die Verursacher ist.
Vielleicht ist es etwas ähnliches bie diesen Gateway.

 

[Thomas_v2.1]

Das Anybus-Gateway meldet sich auch störungsfrei am Profibus, wenn an der anderen Seite nichts angeschlossen ist, es kommen dann eben nur Nullen rein. Das hatte ich ja durch Anschließen und Test an einer anderen CPU, aber mit gleicher Slave-Konfiguration aus dem Original-Projekt überprüft.

Die Geräte wurden mehrfach spannungsfrei gemacht. Und wie geschrieben auch vor Ort über eine kurze Leitung direkt mit der CPU verbunden. Ein "erreichbare Teilenehmer" findet die Baugruppe ja auch immer, nur die CPU will nicht mehr mit ihr sprechen. Als ob dort eine andere Konfiguration für den Slave aktiv ist. Die Anlage hat bis zum Ausfall 10 Jahre in der Konstellation gelaufen, wenn da konzeptionelle Fehler vorhanden wären, dann wäre das wohl schon eher aufgefallen. Und ein schlechter Signalzustand an der Stelle habe ich ja durch anschließen an anderer Stelle meiner Meinung nach auch einigermaßen zuverlässig ausgeschlossen. Ich wurde auch wegen eines anderen Problems zur Anlage bestellt, und erst vor Ort wurde mit mitgeteilt, dass da ja auch noch ein Profibusteilehmer ausgefallen sei. Sonst wäre ich vielleicht besser vorbereitet gewesen und passende Messtechnik mitgenommen.