Beiträge von Maurice

Zitat von fischertech

Vielleicht kannst Du diese EtherCat-Schnittstelle mit TwinCat scannen und dann mit TwinCat die eingeholten Informationen als ESI (XML) exportieren.

Eine solche ESI-Export-Funktion gibt es leider in TwinCAT (3) nicht. Beckhoff arbeitet aber wohl daran.

Ich konnte das Problem leider nicht lösen. Es gibt zwar von Beckhoff ein generisches ESI-File (Beckhoff CXxxxx.xml) und damit lässt sich die B110 auch in WorkVisual einbinden. Allerdings gibt es keine Möglichkeit das tatsächliche Prozessabbild zu konfigurieren.

Musste daher wieder auf die EL6695 ausweichen.

Moin,

Die Beckhoff-IPCs der Serien CX5xx0 / CX20x0 / CX9020 gibt es auch mit EtherCAT-Slave-Optionsschnittstelle (CXxxx0-B110). Hat die schon mal jemand an einer KRC4 zum Laufen bekommen? Das Problem ist, dass es dafür kein ESI-File gibt. Man ist auf die Scan-Funktion des EtherCAT-Masters angewiesen. Solange der Master auch ein TwinCAT-System ist kein Problem. An einer Stäubli-Steuerung geht es mit etwas Gebastel wohl auch. Aber mit WorkVisual?

(Die EL6692 / EL6695 ist mir bekannt.)

Grüße

Zitat von Hermann

- anderer Kollege kommt einen Tag später mit seinem PC: deinstalliert altes WoV, Installiert neues WoV (das vom Kollegen von gestern), installiert die GSD- und sonstigen Beschreibungsdateien
-> Lädt das Projekt vom Roboter, benennt es um und lädt es wieder auf den Roboter
-> Na, was passiert? --> Bus läuft nicht mehr.
- Busaufbau löschen und neu aufbauen --> Bus läuft wieder

Ja, kommt mir bekannt vor... Da sind wir dann in dem Bereich was ich an Kuka alles auszusetzen habe. Im Herzen sind's wohl einfach immer noch Schweißmaschinenbauer... so kommt's mir immer wieder vor.

Zitat von Dominik 0815

Trägheitsmomente: ( Gramm * Quadratmillimeter )
Bezogen auf den Massenmittelpunkt und ausgerichtet auf das Ausgabekoordinatensystem.
[...]
Die KRC 2 Steuerung benötigt jedoch "JX" "JY" und "JZ" also die Hauptträgheitsmomente in [kgm²] was ja 10^- 9 gmm² entspricht. Kann mir jemand sagen, welche der oben aufgelisteten Trägheitsmomente nun für mich bzw. die Steuerung relevant sind?

Keine. Du benötigst die "Hauptachsen der Trägheit und Hauptträgheitsmomente". Die soll dir der Hersteller des Werkzeugs geben. Wenn Du ihm das so mitteilst muss er nur in seinem CAD-Programm den Haken an der richtigen Stelle setzen...

Zitat von WolfHenk

kann auch sein, dass er dem Beckhoff-Koppler nicht sagt "Du, es gibt Bus UND Digitale Sachen.
Zwei verschiedene Busse kann der Kopf eh nicht.
Bau mal die digitalen IOs aus, dann sollte es problemlos gehen.

KUKA hat mit Beckhoff micht gerade einen Glückstreffer gelandet. Nicht umsonst ist der Robot auch mit CP5614 für Profibus lieferbar.

Da muss ich mal kurz höflichst widersprechen:
Die Lösung, intern nur noch Ethercat einzusetzen und alles über Ethercat-Klemmen und -Boxen anzubinden halte ich für einigermaßen genial. Was war das bei den alten Steuerungen für ein Krampf mit der Konfiguration der Siemens-PB-Karten... Erstmal hunderte Megabyte Siemens-Software installieren und was weiß ich.

Jetzt hängen am selben Bus nicht nur interne Digital- / Analog-E/A und Legacy-Feldbusse (in Form von Ethercat-Klemmen), sondern auch externe E/A (Ethercat-Koppler oder -Boxen am X44). Und alles ist an einer Stelle (in WorkVisual) konfigurierbar.

Auch wenn ich sonst an Kuka viel auszusetzen habe, da muss ich sie mal loben!

Vier Brücken fehlen noch:

Sicherer Betriebshalt Kanal A (7-8)
Sicherer Betriebshalt Kanal B (25-26)
Sicherheitshalt Stopp2 Kanal A (9-10)
Sicherheitshalt Stopp2 Kanal B (27-28)

Stand auch schon mal vor dem Problem... Dass keine Meldung ausgegeben wird macht die Fehlersuche in der Tat nicht einfacher.
Wenn man etwas tiefer gräbt wird man jedoch fündig: Diagnose -> Diagnosemonitor -> Da gibt's dann irgendein Safety-Modul.
(Habe gerade keine Steuerung zur Hand um nachzusehen wie es genau heißt.)

Wie bist du vorgegangen? Default-Projekt von der KRC geladen und mit WorkVisual angepasst oder komplett neues Projekt in WorkVisual erstellt?

Zitat von jklos

Wie muss denn der Befehl korrekt heißen?

BAS(#TOOL,2)

Dann werden auch gleich die Lastdaten richtig gesetzt.

Zitat von harzi

Gibt es denn überhaupt Probleme wenn die beiden Netze nicht getrennt sind. Könnt ihr da aus Erfahrung etwas zu sagen?

Wir verwenden für Profinet, WorkVisual, Backups sogar nur eine IP-Adresse, d. h. nur virtual5. Funktioniert problemlos. Die Trennung in virtual5 und virtual6 bringt aus meiner Sicht nur den Vorteil, dass man für Profinet und Windows-Netz unterschiedliche IP-Adressen verwenden kann. Performance-Vorteile bringt es keine, da die Priorisierung von Profinet RT-Daten auf Priority Tagging nach IEEE 802.1Q basiert, d. h. unterhalb der IP-Ebene. Das unterstützt jeder halbwegs aktuelle Managed Switch (muss aber ggfs. explizit aktiviert und konfiguriert werden).

Wir verwenden z. B. meistens kleine Cisco-Kisten (unter 200 Euro).

fischertech: VLANs unterstützt eigentlich jeder Managed Switch, auch die billigen.

Vor dem Problem standen wir auch. Von Kuka gibt es einen Schrank speziell für die KRC4 compact (auf Anfrage, längere Lieferzeit). Ist allerdings so groß wie 'ne "richtige" KRC4 und kostet richtig Geld...

Zitat von Kille

RET_RSIERR = ST_DIGIN (Object1_ID,0,330,0,RSIUNIT_No)
RET_RSIERR = ST_MAP2DIGOUT (Object2_ID,0,Object1_ID,1,330,0)

RET_RSIERR = ST_ON

LOOP
ENDLOOP

RET_RSIERR = ST_OFF

Alles anzeigen

Sollte so funktionieren. Das Einzige, was mir noch auffällt sind die fehlenden Variablendeklarationen in deinem Screenshot. Hast du die versteckt oder vergessen?

Zitat von seeyou77

So nun zur Frage: wie bekomme ich es hin das meine Flanschplatte bzw Achse 6 immer im 45° bzw einem anderen konstanten Winkel zu meiner xy Ebene des Base Koordinaten Systems bleibt, egal wie ich im Raum bewege sollte sie immer den geforderten Winkel einhalten.
Geht das?? Ist das möglich zu realisieren ???

Stichwort "Orientierungsführung"; auf "Konstante Orientierung" einstellen ($ORI_TYPE=#CONSTANT). Dann wird immer die Orientierung des Startpunktes beibehalten.

Zitat von Kille

warum funktioniert es nicht?

Weil Du die RSI-Objekte zwar angelegt, deren Ausführung aber nicht gestartet hast. RSI Start / Stopp geht so:

Zitat

RET=ST_ON()
RET=ST_OFF()

Zitat von Dos 6.22

Gefährlich was du da vorhast. Die Schutztür wird vom Roboter oder der SPS gesteuert?

Habe es so verstanden, dass es in der Anlage keine externe SPS gibt. Da kann die Verwendung der sps.sub als Minimal-SPS durchaus sinnvoll sein.

Zitat von Dos 6.22

Weil dieses zusätzliche Quittieren ist ja eine Schutzfunktion die verhindern soll, dass der Roboter plötzlich loslegt. Und das kann passieren wenn er anfängt sich selber Schutzkreise zu quittieren.

Sobald die Tür zu ist soll er ja "plötzlich loslegen". Und quittieren lässt sich die Tür erst wenn sie zu ist.

Du kannst die Überwachung von $MOVE_ENABLE umgehen. Ich zitiere mal aus der Doku:

Zitat

$CHCK_MOVENA
Wenn die Variable $CHCK_MOVENA den Wert FALSE besitzt, kann
$MOVE_ENABLE umgangen werden. Der Wert der Variablen kann nur in der
Datei C:\KRC\ROBOTER\KRC\STEU\Mada\$OPTION.DAT geändert werden.

Zitat von Twister

Du musst das "T" von "True" klein schreiben. Also "true", dann gehts bei mir. (Siemens S7 Profibus und KRC4 V8.2.x mit Beckhoff-Slave)

Ist kleingeschrieben... hier meine komplette KrcExtConfMsg.xml:

<?xml version="1.0" encoding="UTF-8"?>
<KrcExtConfMsg xsi:noNamespaceSchemaLocation="/Roboter/Config/System/Common/Schemes/KrcExtConfMsg.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <Version Label="">
    <Info Version="KRC V8.2"/>
    <Schema Version="1"/>
  </Version>
  <!-- ============================================================= -->
  <!-- This file allows to change the configured default             -->
  <!-- behaviour for external confirmation for specified             -->
  <!-- messages                                                      -->
  <!-- ============================================================= -->
  <!-- Example:                                                      -->
  <!--            <Message Number="xyz" AllowConfInExt="true" />     -->
  <!--                 ==> allow confirmation in EXT                 -->
  <!--            <Message Number="xyz" AllowConfInExt="false" />    -->
  <!--                 ==> disable confirmation in EXT               -->
  <!-- ============================================================= -->
  <!--  !!! only confirmation messages are allowed to configure !!!  -->
  <!-- ============================================================= -->
  <Message Number="2858" AllowConfInExt="true" />
</KrcExtConfMsg>

Findet jemand einen Fehler? Habe den Verdacht, dass es bei Profinet einfach nicht geht.

Zitat von TCP-Markus

Wenn der Master (SPS) hochgelaufen ist, kann der Slave quittiert werden und sollte sich dann wieder einklinken

Genau so habe ich mir das vorgestellt. Funktioniert leider nicht.

Naja, Anlage ist längst ausgeliefert; beim nächsten Roboter versuche ich es nochmal. Vielleicht liegt es ja an der Software-Version oder so.

Zitat von TCP-Markus

Richtige XML? Tippfehler?

Eben nochmal geprüft. Alles korrekt eingetragen.

Vielleicht geht es wirklich nur bei bestimmten Feldbussen? Quittiert ihr auch einen Profinet-Fehler über Profinet?

Dann funktioniert doch alles? Das Problem erschließt sich mir nicht so ganz...

Moin,

Hat hier schon mal jemand eigene Erweiterungen für das Kuka-HMI programmiert? Von OrangeApps gibt es z. B. ein paar nette Erweiterungen ("SmartPlugins"), die sich in die Kuka-Oberfläche integrieren. Demnach gibt es da irgend eine Plugin-Schnittstelle...

Infos über eine API oder ähnliches sind mir aber noch nicht über den Weg gelaufen. Bei Kuka findet sich zum Thema HMI nur Zenon. Ich möchte aber keine komplett individuelle Oberfläche, sondern nur ein paar kleine Erweiterungen der Kuka-Oberfläche selbst erstellen.