KRC4 Beckhoff EL6695 FSoE Konfiguration

  • Einen wunderschönen.


    Ich habe hier folgendes Setup:
    Beckhoff CX2030
    EL6695-1001 von Kuka
    KR C4 Roboter
    TwinCat3


    Das Problem ist jetzt die EL6695 Klemme, welche von Beckhoff für KUKA hergestellt wird, in TwinCat3 einzubinden.
    Die Klemme will nicht in OP.


    Kuka Hotline Sagt das ist SPS das ist nicht unser Support bereich und Beckhoff sagt die Klemme ist extra für KUKA
    hergestellt also liegt der Support seitens Kuka...tolle Sache immer sowas...


    Hat evtl. jemand schonmal eine EL6695-1001 Klemme mit Twincat3 in betrieb genommen und nutzt die Safety Over Ethercat Funktion?


    Gruß Alex

  • Schritt für Schritt zum Roboterprofi!
  • Moin,


    wir haben mittlerweile 2 Steuerungen mit der Bridge ausgestattet. Eine haben wir nachgerüstet und dabei die Bridge von Beckhoff direkt gekauft.
    Bei der anderen Steuerung haben wir die Bridge direkt mitbestellt.


    Die Inbetriebnahme hat beidermaßen gut funktioniert.
    Denk an die Spannungsversorgung der Bridge sonst kann es zu Problemen kommen.
    Safety Over Ethercat nutzen wir an dieser Stelle nicht.


    Gruß Jan

  • Auf der TC3 Seite. Gibt es dort evtl etwas spezielles zu beachten? Wir habe die Klemme eingebunden und Simulate Device die ESI Datei aus WorkVisual geladen. Es kommt dann immer ein Fehler mit "Check Vendor ID".
    Es ist noch kein Kabel an der Klemme für den Robbi.

  • Deine Infos sind ein bisschen sehr sehr spärlich...


    Heisst das die Klemme ist rein physikalisch mit der E-Bus Seite dem Master der CX zugeordnet, und RJ-Seite der KRC?


    Kannst du die Klemme auf der Sekundärseite (RJ-45) in WorkVisual einbinden? Die beiden Seiten laufen ja unabhängig voneinander.


    Warum ein "Simulated Device", und weshalb für den CX-Master die ESI/XML von WorkVisual?
    Was zeigt denn CoE Online auf TwinCAT Seite über die Klemme an, dort kannst du ja (unter Identity) auch die Vendor-ID der Klemme anzeigen lassen. Mal einen Konfigurationsvergleich gemacht?


    @Jannn: Die neue Klemme bezieht ihre 24V-Versorgung redundant, entweder vom E-Bus oder vom Frontstecker.

    APT Techniques GmbH<br />Software-Entwicklung für Roboter &amp; SPS.

  • da war ja was...


    Nach etlichen Mails und Telefonaten mit dem KUKA und Beckhoff Support geht es jetzt ein wenig.


    Die Klemme hätte nicht SPS Seitig sein dürfen. Für die FSoE Kommunikaiton muss die Klemme Primärseitig am Roboter angebunden sein und via WorkVisual eingerichtet werden.


    Der Roboter geht nun mit Ethercat auf die EK1100 und an dieser ist die EL6695 welche mit der Sekundärseite zur SPS geht.
    Das mit dem Simulatet Device ist damit auch hinfällig da es so einfach falsch koniguriert war.


    SPS Seitig über einen zweiten Ethercat Master direct an der SPS (siehe Bild)


    Der austausch der Standart IOs funktioniert aber die sicheren Signale noch nicht.


    Der Fehler "Kommunikationsfehler sicheres Gerät KRC4 primary EL6695-1001" ist der letzte Fehler der immoment ansteht.


    Die FSoE Adressen stimmen überein und SPS Seitig ist alles OP und auch die "FSoE Message" ist richtig zur EL6695 sekundary verknüpft . Ich warte gerade noch auf einen neuen Lösungsansatz des Supports.


    Gruß Alex

  • Hallo zusammen,


    ich greife das Thema nochmal auf. Ich nehme gerade zum ersten Mal einen KUKA an einer Beckhoff in Betrieb.


    Irgendwie habe ich noch grundsätzliche Schwierigkeiten. Beim Scannen aus TC3 heraus findet er die "KUKA secondary EL6695-1001" zwar, allerdings fehlt TC3 die Gerätebeschreibungsdatei (obwohl diese aktualisiert sind - sowie das TC3 auch den letzten Stand hat).


    Es sollen nur 64 Byte Ein-/Ausgangsdaten konfiguriert werden. Sicherheit geht ganz normal über die X11 - ohne FSoE-Objekte. Siehe Konfig WoV...


    Wie schon beschrieben, habe auch ich die Erfahrungen machen müssen, dass Beckhoff auf Kuka verweist und anders herum. Keiner will die Gerätebeschreibungsdatei haben!?


    Was war bei euch des Rätsels Lösung? :kopfkratz:

  • Die GSD "Kuka_EL6695sec.xml" findest du im WV-Installations-Verzeichnis "DeviceDescriptions\ESISec\".
    Die GSD "Kuka_EL6695prim.xml" im Verzeichnis "DeviceDescriptions\ESI\".


    Habe gerade heute ähnliche (TC2) Konstellation in Betrieb genommen. WV 4.0.10 hat sich durch mehrere Abstürze gewehrt die neuste Version und die Byte-Anzahl-Änderungen anzunehmen. Nach Löschen der vorkonfigurierten Geräte und zig Neustarts hat es dann doch noch geklappt.


    Es gibt übrigens eine extra KUKA-Doku für die EL6695.

  • Habe gerade auch Probleme eine Beckhoff-EL6695 zum Laufen, zu bekommen.
    Primär ist die KRC4 dran. Sekundär Beckhoff des Kunden. (Kunde hat hier bei TwinCat "FreeRun" eingestellt)
    Verteilte Uhren sind deaktiviert in WoV. (FreeRun kann ich leider nicht aktivieren, da diese Einstellung zwar eingestellt werden kann, aber von WoV nicht übernommen wird).
    Da wurde geschrieben: "Es gibt übrigens eine extra KUKA-Doku für die EL6695".
    Hab die nirgends gefunden. Hat die jemand?
    Übrigens mache ich über eine zusätzliche Klemme EL6695 eine Kommunikation zwischen zwei KRC4's Da läuft alles super.

  • Also mein Problem ist mittlerweile gelöst.
    Der Kunde hat in seiner Beckhoff-SPS dem Adressbereich den er zu der KRC4 senden will Arrays zugeordnet. Die Arrays waren zwar auch als Bytes aufgebaut, aber halt Arrays. Nun kopiert er die Arrrays zuerst in Bytes und die Bytes in den Adressbereich. Es tut.
    Danke für die Hilfe!

  • Hatte dasselbe Problem, Karte wollte nicht von PreOp -> SafeOp booten.

    Hat sich herausgestellt das die Karte nicht mit Array of BYTE oder ähnlichem zurande kommt. Einfach BYTE auf Beckhoff Seite mehrfach deklarieren und es lief.

Erstelle ein Benutzerkonto oder melde dich an um zu kommentieren

Du musst ein Benutzerkonto haben um einen Kommentar hinterlassen zu können

Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen. Geht einfach!
Neues Benutzerkonto erstellen
Anmelden
Du hast bereits ein Benutzerkonto? Melde dich hier an.
Jetzt anmelden