Beiträge von fubini

What does not work for you with the offered solution in

Beitrag

RE: Probleme mit "$ASYNC_AXIS"

Moinsens,

das hat was mit der Einstellung von $Async_mode zu tun:

Das hier konfigurierte Verhalten gilt auch bei impliziter Satzanwahl, z. B. beim Rückwärtsfahren, Punkt neu teachen, Punkt löschen oder beim Abfahren eines Programms in den Programmablaufarten MSTEP und ISTEP.

• Bit 1 = 0: Default-ModusBei Satzanwahl wird die Systemvariable $ASYNC_AXIS auf den Wert von $EX_AX_ASYNC gesetzt.
• Bit 1 = 1: Modus 2Bei Satzanwahl wird die Systemvariable $ASYNC_AXIS nicht geändert.

Setz den mal auf…

Martin Huber

11. Mai 2022

Fubini

Ist es vielleicht ein Platzproblem? Ist dein Stick einfach zu klein für beide Partitionen bei dem einen Roboter? Auf dem Stick gib es ein Logfile, das normalerweise etwas genauere Fehlerinfo bereitstellt, falls welche auftreten.

Fubini

Lass doch erstmal für den Test deiner Sequenz von Transformationsmatrizen eine eigene Implementierung weg und rechne direkt auf der Steuerung. Dazu kannst du das auch direkt unter Anzeige->Variable->Einzeln eingeben. Da kannst du auch direkt die Dollarvariablen verwenden.

Ausserdem hast du eine Zusatzachse. Ist da die Kopplung aktiv? Dann kannst du auch auf $Base_c schauen, dass die das aktuelle base gibt.

Diese Diskussion hilft vielleicht auch noch weiter

Ich verstehe auch deine Beschreibung nicht ganz. Um auf nullframe im Tool also auf den Flansch zurückzurechnen brauchst du nur das aktuelle Werkzeug von der aktuellen Position abziehen also

$POS_ACT:INV_POS($TOOL_C)

willst du dann zurück in die Welt ändert sich das zu

$BASE_C:$POS_ACT:INV_POS($TOOL_C)

Dabei ist insbesondere auch wichtig die Reihenfolge richtig einzuhalten, da Framemultiplikation nicht kommutativ ist also f1:f2 ist nicht dasselbe wie f2:f1. Daher vermute ich dass

Zitat von Daval

robo_pos_trafo_B1W0 = inverse(FLANSCH2TOOL_trafo_W1) * robo_pos_trafo_B1W1

sowieso falsch herum ist.

Fubini

Beim achspezifischen Handverfahren ist das wenn ich mich recht erinnere normal. Nur beim kartesischen Handverfahren sollte die Kopplung über den EO an sein bzw berücksichtigt werden. Ist auch bei externen Basekinematiken so.

Fubini

Nachdem der Status 18 ist und damit insbesondere die Punkte absolutgenau geteached (Bit3!=0) wurden ist vielicht die Absolutgenauigkeit deines Roboters nicht berücksichtigt. Würde mich wundern wenn OrangeEdit das könnte.

Außerdem ist B nahe bei +-90 Grad. Da kann die Eulersingularität (GimbalLock) auch noch mit reinspucken.

Ich hab aber auch ehrlicherweise deine Aufgabenstellung nicht ganz verstanden. Kann aber auch daran liegen, dass ich mit OrangeEdit nicht so vertraut bin.

Fubini

Maximal kannst du mehrere ILFs gleichzeitig markieren und dann alle markierten gleichzeitig editieren.

Fubini

$NULLFRAME ist ja auch nur ein BASE, das zufällig im Roboterfuss aks $ROBROOT liegt. Ändert auch nichts an der Vorgehensweise.

Zitat von Stern_1974

Hallo Fubini;

diesen Hilfsprogramm finde ich leider nicht im Verzeichnis.

Mit dem Doppelpunktoperator hab ich noch nie gearbeitet.

TCP Verschiebung eines Werkzeug - KUKA Roboter - Roboterforum.de - die Industrieroboter und Cobot Community

Wirklich nicht? Ist normalerweise immer dabei gewesen in der Vergangenheit. Wie hast du danach gesucht? Sollte zusätzlich auch auf dem Installationsmedium deiner KSS zu finden sein.

Doppelpunktoperator ist nichts anderes als die Multiplikation zweier Frames (homogener Koordinatentransformationen) miteinander, siehe auch

Homogene Koordinaten – Wikipedia

x_value of wrist root point - KUKA Robot Forum - Robotforum - Support and discussion community for industrial robots and cobots (robot-forum.com). Wäre dann in deinem Fall etwa

POSITION_NEU = BASE_NEU:INV_POS(BASE_ALT):POSITION_ALT:INV_POS(TOOL_ALT):TOOL_NEU

ChangePos.exe macht nichts anderes außer das es über ein INI-File steuert was du genau willst und damit durch ein dat-File durchgeht und alle Posen darin entsprechend INI-File umrechnet.

Fubini

Unter C:\KRC\UTIL gibt es ein kleines Hilfsprogramm changepos.exe (oder so ähnlich). Damit kann man Punkte in dat-files auf andere Bezugssysteme umrechnen lassen.

So einen Konvertierer könnte man sich natürlich auch in KRL über den Doppelpunktoperator und INV_POS selbst bauen.

Fubini

OK. Je nachdem ob die Verschiebung dann im Base oder im Toolsystem stattfindet müsstest du das dann entweder über den Doppelpunkt Operator nachbauen können oder du verschiebst gleich das Bezugssystem $BASE bzw. $TOOL.

FRAME A

A : SHIFT ;Verschiebung in Tool

SHIFT : A ; Verschiebung in Base

Fubini.

Was macht UP relativ genau? Könnte es vielleicht sowas wie TRIGGER sein? Man kann bei TRIGGER entlang eine Bewegungsbahn einen Ort und einen zeitlichen Shift eingeben an dem ein Unterprogramm ausgeführt werden soll.

Ich mein mich auch dunkel zu erinnern, dasses ganz früher auch mal eine Funktionalität SYN OUT gab, die wohl ein Vorläufer der heutigen Trigger war.

Fubini

KUKA Portal, siehe READ FIRST... - KUKA Robot Forum - Robotforum - Support and discussion community for industrial robots and cobots (robot-forum.com)

Fubini

Könnte sich um Pendeln handeln. Das wird bei KUKA entweder über Techpakete z.B. ARCTECH gemacht oder man baut sich das über den Funktionsgenerator nach. Ich muss aber zugeben das KRC1 vor meiner Zeit war. Daher kanns durchaus sein, dass es das alles damals noch nicht gab. Schau also mal nach welche Techpakete du installiert hast und hohl dir dann die Doku dazu aus dem KUKA Portal, siehe Forum ReadFirst.

Fubini

Erstmal sind die Bremsen natürlich ein Verschleißteil. Wenn ihr dauerhaft mit zu hohen Momenten den Bremsentest macht kann das schon zu erhöhtem Verschleiß führen. Die Lastdaten gehen ja mit ein mit was für Momenten gegen die Bremsen gefahren wird.

Bei einem KR10 sind 1.8kg vs. 3.5 kg halt schon ein signifikanter Unterschied. Hängt halt auch immer noch ein bisschen von Ausladung und Trägheiten ab wo man sich da im Traglastdiagramm bewegt.

Insofern finde ich die Aussage von KUKA erstmal gar nicht so falsch falls die anderen Einflussfaktoren dazu führen das das Traglastdiagramm nicht eingehalten wird. Solltest du dir für deine Maschine mal anschauen wo im Traglastdiagramm du unterwegs bist. Leider verrätst du ja die anderen Werte die du verwendest nicht.

Fubini

Nein kannst du eben nicht. Das ist genau das was ich oben meinte. Ohne Justageprozedur/Justagefahrt kannst du das nicht einfach irgendwo eingeben. Wenn Justage so einfach wäre würde man ja die Werte ab Werk gesagt bekommen und EMD/EMT bräuchte es nie. Du musst neu justieren über die HMI. Das kannst du entweder mit EMD/EMT oder eben wie in den Links oben beschrieben ohne EMD/EMT. Die Geber bei KUKA sind keine Absolutgeber sondern Inkrementalgeber!

Fubini

Ich verstehe die Frage so nicht. Was willst du genau erreichen? Die Daten des Nullpunkts in dem Sinne gibt es nicht. Das ist kein einfacher Wert den man speichert und später wieder setzen kann. Unter sehr begrenzten Umständen geht das über Justage restaurieren aber nicht allgemein. Es geht nur über die Justagemenüs.

Fubini

Wenn es nicht auf die letzte Genauigkeit ankommt kannst du auch über eine Messuhr oder mit einem Metalstift justieren. Ist aber sicher ungenauer und auch schlechter reproduzierbar.

https: //www.robot-forum.com/robotforum/thread/43465-mastering-with-dial-gauge/?postID=198768#post198768

Fubini

Fubini

Ist die Bewegung wo es passiert ein PTP? Dann wird der Turn von Achse 1 bei der fehlerhaften Bewegung nicht stimmen und der Roboter würde A1 links herum drehen statt rechts herum oder umgekehrt. Und bei dieser Achskonfiguration über den Endschalter fahren müssen. Einfach mal das Turn Bit bei der Bewegung flippen und dann vorsichtig testen.

Fubini

Jetzt widersprichst dir aber selber

Zitat von observer

Ich schaetze, dass es das Echtzeitbetriebssystem ist, dass die CPU so stark auslastet, denn die HMI reagiert sehr schnell.

Zitat von observer

Waehrend des Speicherns der Datei pendelt sie dann zwischen 20 - 30 %. Waehrend die KUKA HMI beim Speichern komplett einfriert, kann ich Windows im Hintergrund noch ganz normal bedienen.

Friert jetzt die KUKA HMI ein oder nicht. Btw. Echtzeit und HMI beim KUKA teilen sich normalerweise einen Core. Ist glaub ich bei OL auch nicht anders. KUKA HMI ist dabei nicht Teil des Echtzeitsystems sondern eine Windowsapplikation.

Fubini