Beckhoff: Probleme mit ProfiSafe (EL6631)

[TomTom01]

Zuviel Werbung?
-> Hier kostenlos registrieren

Guten Tag zusammen,

wir sind gerade auf einer Inbetriebname mit einer Beckhoff Steuerung und haben wohl ein Fehler bei dem aufbau der Klemmen gemacht.

Aktueller Fehler: Über eine EL6631 haben wir ein Kuka Krc4 Roboter mit Profisafe konfiguriert und angeschlossen. Watchdog Fehler wird gemeldet.

Aktueller Aufbau:

CX5240-EL6910-Einige Safety I/Os - Standart I/Os - EL9410 - Standart I/os- EL6631 -> Profisafe KUKA

....jetzt habe ich gelesen, das dieser Aufbau wohl so gar nicht zulässig ist, es wird die Klemme EL9930 für den ProfiSafe Abschluss benötigt. Habt Ihr Erfahrung in mit dem Thema bzw. dieser Klemme? Kann das der Fehler sein?

Vielen Dank!

Grüße
TomTom

 

[Glasesba]

Die EL9930 ist nur ein lizenrechtliches Thema, funktionieren tut es auch ohne die. Welche TC3 Version hast du? Ich hatte demletzt auch so ein Problem mit Profisafe Watchdog Fehler als ich die neue 4024.32 genutzt hatte. Ich bin dann zurück auf die .29 (nur auf meinem Rechner, die Runtime auf dem CX läuft weiterhin .32). Damit ging es dann wieder, ich hab das Thema dann an dem Support gemeldet.

 

[TomTom01]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danke für die schnelle Antwort!
Ich habe die auf der CX die 4024.11, auf meinem Rechner die 4024.29.

 

[Guga]

Kannst du etwas konkreter werden bzgl. dem Fehler? Bei einem Problem ist es per Definition so dass die Safty-Ebene als erstes Probleme zeigt - auch wenn die Problematik woanders liegt?

Funktioniert die Kommunikation über ProfiSafe/ProfiNet?
Wie sieht es mit dem EtherCAT aus und dem Status der EL6631? Zykluszeit des EtherCATs (langsamste Task ..)?
Tritt der Watchdog nur mit dem Kuka-Roboter auf?
Hast du den default-Watchdog (dürfte 100ms sein) für die Kommunikation im Alias mal auf 150msec gesetzt.

Ich gehe davon aus das es nur eine Kleinigkeit ist - aber wie gesagt ohne mehr Hintergrund (z.B. Screenshots..) wird es schwierig mit meiner Kristallkugel

Guga

 

[TomTom01]

Hallo Guga,

danke für die Antwort.

Jetzt versuche ich alles bisherigen Fragen zu beantworten.
Das Profinet funktioniert auch mit dem aktiven Fehler auf der Safetyebene. Der EL6631 arbeitet ohne Probleme weiter.
Der Watchdogfehler tritt genau dann auf, wenn ich den Roboter als Profisafe einfüge und die dann das Safety Programm in die Steuerung lade.
Ohne Roboter läuft alles ohne Probleme.
Den Watchdog habe ich zu testzwecken mal auf 150 und auch 500ms gestellt, kein erfolg.
Die Safetyparameter habe ich mit denen von Kuka verglichen, die passen.
Der Kuka wird ohne Safetyanbindung fehlerfrei im Profinet erkannt.

Grüße

 

[oliver.tonn]

Zuviel Werbung?
-> Hier kostenlos registrieren

CX5240-EL6910-Einige Safety I/Os - Standart I/Os - EL9410 - Standart I/os- EL6631 -> Profisafe KUKA

....jetzt habe ich gelesen, das dieser Aufbau wohl so gar nicht zulässig ist, es wird die Klemme EL9930 für den ProfiSafe Abschluss benötigt. Habt Ihr Erfahrung in mit dem Thema bzw. dieser Klemme? Kann das der Fehler sein?

Bei Deinem Aufbau benötigst Du die EL9930 nicht. Die Nutzung hat patentrechtliche Gründe. Siemens hält verschiedene Patente bezüglich des Profisafe. In einem der Patente heißt es wohl, dass Profisafe Pakete nur über Profinet, Profibus oder einen Rückwandbus geführt werden dürfen, nicht aber über andere Medien. Der E-Bus am CX5240 zählt als Rückwandbus und, da die Kommunikation sich bei Dir auf diesen und Profinet beschränkt ist alles in Ordnung.
Anders sähe es aus, wenn Du am Ende z.B. eine EK1110 oder eine EK1122 hättest, dann würde es einen Übergang durch diese Klemmen vom E-Bus zu Ethernet/EtherCAT geben und das wäre nicht zulässig. In dem Fall musst Du vor der EK Klemme die EL9930 setzen.
Ansonsten schau mal in die Bedienungsanleitung von der EL9930, da ist alles gut beschrieben.

 

[Guga]

Wie überzeugt bist du von denen ProfiSAFE-Parametern?
Die projektspezifischen (also nicht Device-spezifischen) wären:
- F_Source_Add: Safty Adresse des Masters = EL6910.
- F_Dest_Add: Safty-Adresse des Slaves. Wird von Slave vorgegeben und muss im System eineindeutig sein.
- F_WD_Time: Watchdog in msec
- F_Par_CRC: Auf Basis seiner Parameter berechnet der ProfiNet MAster eine/ seine Parameter CRC. Wird somit automatisch berechnet.

Und in dem GUI der Safety Connection gibt es mehrere Spalten. Der Default sagt bei dir "BlockID=1", du hast aber eine 0 konfiguriert. Mit Absicht? Hast du den Default mal ausprobiert ?
Die Buttons im Dialog hast du bedient sodass die Safty-Parameter auch sichtbar im ProfiSAFE-Teilnehmer sich dort wiederfinden?

Guga

 

[TomTom01]

Ich habe jetzt nochmal alle ProfiSafe Parameter kontroliert. Es sollte so passen.
Ich bis vor einer Woche haben wir den selben Robi mit einer S7 über Profisafe betrieben, ohne Probleme. Ich habe auch nochmal im
TIA Projekt ale Parameter kontroliert und mit dem TC abgeglichen.

der "BlockID" Parameter steht auf "R" also den kann man wohl nur lesen. Bekomme ihn mit default auch nicht auf 1 beschrieben.

Ist die "Sichere Adresse" ist gleich der "F_Dest_Add"?

Viele Grüße

 

[Glasesba]

Zuviel Werbung?
-> Hier kostenlos registrieren

In deinem Screenshot steht die Watchdogzeit im Safety Programm auf 500ms, der I/O TreeItem Value aber auf 100. HW und Safetyprogramm müssen aber gleich sein. Ist in der TwinSAFE Gruppe den noch was anderes, ist das alles IO? Kann ja auch ein Folgefehler sein weil die Guppe wegen eines anderen Fehlers stoppt.

 

[TomTom01]

Hallo Glasesba, das stimmt. Die WD habe ich mittlerweile auch angepasst. Es stehen alle auf 500.
War noch leider nicht die Ursache.

 

[TomTom01]

Die F_Souce_Add ist doch die Sichere Adresse der EL6910, also die Adresse, die man über die Dip Schalter einstellt, oder?

 

[oliver.tonn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die F_Souce_Add ist doch die Sichere Adresse der EL6910, also die Adresse, die man über die Dip Schalter einstellt, oder?

Ja, richtig. Darf denn die FiPar_CRC 0 sein? Bei meiner Anwendung (Einbindung von Siemens Sirius in TC 3) führte das zu Problemen und ich musste den Wert auf 1 setzen, ich meine aber es war kein Watchdog Fehler.

 

[TomTom01]

Ich habe eben zum Testzwecken nochmal eine S7 1200F eingesetzt. Selbe Parmeter, Verbindung ohne Probleme direkt aufgebaut!

Was mir aufgefallen ist, bei der S7 kann ich den Parameter F_Block_ID aktiv auf 1 setzten.
Ist er auf 1, steht die Verbindung. Setzte ich ihn auf 0 habe ich den selben Fehler wie bei der Beckhoff.
Was sagt der Parameter aus?

 

[oliver.tonn]

Dann lad doch mal im Safety Knoten beim Alias Device die Default Werte als aktuelle Werte, dann sollte F_Block_ID auch auf 1 gesetzt werden, denn der Default Wert ist ja 1, anschließend musst Du die anderen Werte vermutlich wieder anpassen, weil die überschrieben wurden.
Was der Parameter bedeutet weiß ich leider auch nicht.

 

[TomTom01]

Zuviel Werbung?
-> Hier kostenlos registrieren

Scheint nicht zu funktionieren, der Wert wird wohl direkt wieder mit 0 beschrieben.
Alles seltsam, ich habe eben gesehn das ich sogar Prozessdaten (Zustände) auf dem Kuka Device lesen kann . Also die Verbindung scheint
schon mittlerweile aufgebaut zu sein. Zumindestmal auf seitens Beckhoff. der Watchdog fehler ist auch "erstaml weg" allerdings wird auf seitens KUKA gemeldet "Kommunikationsfehler sicheres Gerät ProfiNet Device".

Was habe ich geändert:
Safety ID seitens Kuka geändert. Diese ist nun 10. Kompette Projektierung nochmals in den Kuka geladen.
Adresse in TC3 angepasst und hochgeladen.

Gibt es noch eine möglichkeit außer "ErrorAckmowledgement" was in der TC Safty Umgebung zu quittiern?
Vielleicht fehlt jetzt noch eine Quittierung?

 

[Glasesba]

Ist denn in der TwinSafe Gruppe noch etwas anderes? In einem deiner Screenshots sieht man eine Meldung von einem "EDM Fault". Nicht das du eigentlich ganz woanders ein Problem hast. Quittieren geht ja über das Error Acknowledge der Gruppe.

 

[TomTom01]

Jetzt habe ich mir Beckhoff zu Unterstützung dazu genommen. (Die sind wirklich super nett und unkompliziert, das muss man mal sagen! )
Wir waren eben gemeinsam 1 Stunde remote auf meinem Rechner und haben
alles kontrolliert und ein paar Sachen ausprobiert aber bis jetzt ohne Erfolg. Morgen geht die Fehlersuche weiter. Der Support Mitarbeiter will sich ua. auch schlau machen was genau das F_Block_ID beschreibt.

 

[TomTom01]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wir sind ein Schritt weiter:

Laut Beckhoff und KUKA ist die Klemme 6631 über Profisafe inoffiziel nicht kompatibel mit dem Kuka KRC4. Das ganze wurde auch mal
in einer Testumgebung von Beckhoff getestet, aber hatte auch nicht funktioniert. Die Lösung ist der Weg über Ethercat.

Jetzt muss ich mir überlegen, wie ich das ganze umsetzte.....die langen Lieferzeiten machen es nicht einfacher

 

[oliver.tonn]

Wir sind ein Schritt weiter:

Laut Beckhoff und KUKA ist die Klemme 6631 über Profisafe inoffiziel nicht kompatibel mit dem Kuka KRC4. Das ganze wurde auch mal
in einer Testumgebung von Beckhoff getestet, aber hatte auch nicht funktioniert. Die Lösung ist der Weg über Ethercat.

Jetzt muss ich mir überlegen, wie ich das ganze umsetzte.....die langen Lieferzeiten machen es nicht einfacher

Rein aus Interesse, was hat sich in der Angelegenheit getan?

 

[TomTom01]

Guten Morgen,

wie oben beschrieben braucht man für eine saubere Failsafe Verbindung zwischen KUKA KRC4 zu Beckhoff eine 6695. Das ganze ist wohl über Ethercat kein problem und der Standard bei einer Failsafeverbindung zwischen einem KRC4 und einer Beckhoff PLC. Aber die Klemme haben wir momentan nicht, also haben wir eine nicht besonders schöne aber funktionierende Lösung umgesetzt (Bis die EL6695 da ist):

Wir haben eine 1200er Failsafe dazwischen gesetzt.

S7 1200 Failsafe Controller
KUKA KCR5 Failsafe Device
EL6631-0010 an Beckhoff auch als Device (Zum Glück hatten wir noch eine EL6631 als Device im Lager)

Die Signale zwischen KUKA und Beckhoff werden nun zwischen der S71200 gemappt. Die S7 dient wirklich nur als "Tunnel".
Erstmal kein schöne Lösung aber wir konnten die Anlage Inbetriebnehmen.

Viele Grüße