Posts by BenjaminBihler

Hallo,

mir sind zwei Einschränkungen für KRL-Programme bekannt:
- Eine Programmdatei darf nicht mehr als 255 Funktionen enthalten.
- Eine Programmdatei darf nicht länger als 32768 Zeilen sein. Diese Einschränkung ist allerdings schwammig: wenn viele Variablen angelegt sind, sind laut KUKA schon weniger als 32768 Programmzeilen kritisch.

Kennt jemand noch weitere Obergrenzen? Mich würde zum Beispiel interessieren, wieviele Variablen pro Funktion angelegt werden dürfen, oder wieviele Zeilen eine Funktion haben darf.

Danke für die Antwort.

Viele Grüße,
Benjamin

Okay, probier ich aus! Vielen Dank!

Hallo zusammen,

gibt es eine Möglichkeit vorzugeben, welche A6-Stellung bei dem Wert A6=0 eingenommen werden soll?

Der Grund ist folgender: bei der Herstellung eines Werkzeuganschlusses, mit dem das Werkzeug am Roboterflansch befestigt werden soll, ist was schiefgelaufen. Jetzt ist der Anschluß so, daß das Werkzeug bei A6=0 schräg im Raum stehen würde, was für den Bediener seltsam und ungewohnt wäre. Wenn ich den TCP richtig (mit der Verdrehung) definiere, kann ich natürlich mit dem Werkzeug korrekt arbeiten, nur wenn der Bediener eine definierte Nullstellung anfahren wollte, würde er sich jedesmal über die unerwartete Werkzeugstellung ärgern.

Soweit ich weiß kann man über die Justage die A6-Stellung bei A6=0 festlegen. Aber das geht wohl dann schief, weil die Steuerung davon ausgeht, daß ich die A6 "normal" justiert habe und nicht eine künstliche werkzeugabhängige Verdrehung eingebaut habe, oder?

Gibt es eine elegante Möglichkeit, die Nullstellung der A6 beliebig festzulegen ohne negative Konsequenzen für die Bahnplanung?

Vielen Dank!
Benjamin

Ich habe weitergespielt und versuche mal, meine eigenen Fragen zu beantworten:

Woher die Fehlermeldung "Value assignment inadmissible" kam, weiß ich nicht. Die KUKA-Fehlermeldungen sind meines Erachtens meist mehr als nichtssagend, sie sind fast wie Hohn! Ich habe das Projekt und die externe Achse in WorkVisual neu aufgesetzt und dann kam die Fehlermeldung nicht mehr! So etwas ist echt zum Heulen!

Außerdem: ich glaube jetzt verstanden zu haben, daß meine Vermutung richtig war: ich brauch keine Einträge in der Datei $config.dat. Durch die Befehle

DECL FRAME PART_BASE_DATA
$BASE=EK({X 0, Y 0, Z 0, A 0, B 0, C 0},#EASYS,PART_BASE_DATA)

wird die _erste_ externe Kinematik (durch das "A" in #EASYS festgelegt) aktiviert. Der erste übergebene Frame ist der Root der externen Kinematik, der letzte Frame ist der gewünschte Base-Frame.

Ich versuche mal, mit diesen Ideen weiterzukommen.

Was ich mich ernsthaft frage: bin ich der einzige, der diese Probleme hat? Oder benutzen so wenige externe Kinematiken? Oder kennen sich von Anfang an (durch Schulungen?) so gut aus, daß diese ganzen Probleme, die ich habe, nicht auftreten?

Hallo Hermann!

Quote from Hermann

Zu 1 u. 2 kann ich nichts sagen,
denn zu 3: hab' das Zeug immer von Hand eingetragen. WoV trau' ich da nicht, bzw. wenn man's von Hand einträgt, dann steht's da auch.
Such' mal hier im Forum, da gibt's schon einiges z.Bsp:
https://www.roboterforum.de/roboter-forum/…ngeben/msg16572
oder
https://www.roboterforum.de/roboter-forum/…esucht/msg52726

Zu 4: Siehe auch Link von oben. Man sollte im Programm schon eine gekoppelte Base angeben, ansonsten fährt der Roboter ja wohl im Base 0.

Display More

Danke für den Hinweis. Ich antworte erst jetzt, weil ich so lange herumprobiert habe. Irgendwie komme ich nicht weiter und ich weiß nicht genau warum.

Meine Probleme sind die folgenden:

1. Wenn ich in WorkVisual eine externe Achse hinzufüge und deren Maschinendatenkonfiguration eingebe, dann werden von WorkVisual in der Datei $machine.dat die Zeilen

$EX_KIN
$ET1_AX
$ET1_NAME
$ET1_TA1KR
$ET1_TA2A1

und so weiter mit den von mir eingegebenen Daten befüllt. Das ist super, das verstehe ich und alle von mir eingegebenen Daten finde ich dort wieder.
Mir ist dann aber noch nicht klar, was eine "gekoppelte Base" eigentlich ist und wie ich diese definiere und aktiviere. In den Beiträgen im Forum steht oft dieser Befehl für die Aktivierung:

$BASE=EK(MACHINE_DEF[2].ROOT,MACHINE_DEF[2].MECH_TYPE,BASE_DATA[17]:{x 0,y 0,z 0,a 0,b 0,c 0})

Mein Verständnisproblem dabei ist: wo wird dabei eigentlich festgelegt, daß ich meine erste externe Kinematik aktivieren will? MACHINE_DEF[2].ROOT und BASE_DATA[17] sind doch nur Frames?! Oder ist es so, daß wenn MACHINE_DEF[2].MECH_TYPE den Wert #EASYS hat, daß das dann die _erste_ externe Kinematik ist? Und bei #EBSYS wäre es die _zweite_? Und so weiter?

2. Mein nächstes Problem ist, daß der Befehl

$BASE=EK(MACHINE_DEF[2].ROOT,MACHINE_DEF[2].MECH_TYPE,BASE_DATA[17]:{x 0,y 0,z 0,a 0,b 0,c 0})

nach der Definition in WorkVisual noch nicht funktioniert. Die MACHINE_DEF[]-Daten sind nämlich nicht vorhanden. Ich habe aber schon festgestellt, daß ich diese Daten definieren kann, wenn ich in Office Lite die Konfiguration

Menü->Start-up->Calibrate->Base->Numeric input und
Menü->Start-up->Calibrate->External kinematic system->Root point (numeric)

durchführe. Ist das die richtige Vorgehensweise? Dadurch wird in der $config.dat eine Zeile

MACHINE_DEF[2]={...}

eingetragen.

Leider kann ich meine Programme danach nicht mehr ausführen. Bereits im INI-Fold in der Zeile

BASISTECH INI

tritt die Fehlermeldung "Value assignment inadmissible" auf. Ich habe nicht feststellen können, woran das liegt. Muß man neben den Konfigurationspunkten Base->Numeric input und External kinematic system->Root point (numeric) noch mehr konfigurieren?

Wenn ich External kinematic system->Offset (numeric) eingeben will, dann kommt immer die Fehlermeldung "External machine must be calibrated first". Aber wie kann ich die externe Achse denn virtuell kalibrieren?

Für Hinweise, Anregungen und Erklärungen wäre ich sehr dankbar. Ich habe bisher die Dokumentationen KS_83_SI_de.pdf und KSS_83_configuration_of_kinematic_systems_de.pdf von KUKA studiert und auch hier im Forum und per Google viel gesucht, aber ich bin noch nicht schlauer.

Ciao,
Benjamin

Hallo,

ich plane Roboterbahnen in einem eigenen CAD/CAM-System und muß dafür in Zukunft auch Linearachsen (als BASE-Kinematiken, also zum Verschieben unserer Werkstückträger) einbeziehen. Um das machen zu können, wollte ich gerne mit WorkVisual 3.0, KUKA Sim Pro 2.2.1 und KUKA OfficeLite (KR C V8.2.16) eine ganz primitiv vorkonfigurierte Linearachse als BASE-Kinematik mit mathematischer Kopplung simulieren. Leider scheitere ich.

Könnte mir jemand einen Tip geben?

Meine Vorgehensweise ist folgende:

1. In WorkVisual lege ich in einem Standardprojekt mit einem Roboter unter "Geräte\Steuerung" eine Linearachse vom Typ "Generic 1 Axis machine" an. Unter "Geometrie" laß ich diese Achse auf derselben Ebene wie den Roboter, wodurch es eine BASE-Kinematik wird (für ROBROOT-Kinematiken müsste man den Roboter auf den Flansch der Achse ziehen).
2. Ich gehe mit der rechten Maustaste auf meine Linearachse, wähle "Maschinendatenkonfiguration" und gebe dort Werte ein, die zum größten Teil den Default-Werten entsprechen. Bei "Achsenkennung" wähle ich "Linear". Unter Transformation der Achse habe ich alle Werte auf 0 gelassen. Das müsste doch bedeuten, daß die Achse parallel zum Roboter ausgerichtet ist, sich also in "Roboterblickrichtung" bewegen wird.
3. Ich installiere das Projekt nach Office Lite. Was mich wundert: in der Datei $config.dat des Projekts ist die Zeile MACHINE_DEF[2] unverändert. Bei manchen Codebeispielen für externe Achsen wird in der Base-Definition auf MACHINE_DEF[2] verwiesen. Brauche ich das nicht auch? Muß ich MACHINE_DEF[2] von Hand definieren?
4. Wenn ich ein Programm schreibe und die folgenden Testzeilen eingebe, dann bewegt sich der Roboter zwischen LIN Test1 und LIN Test3 nicht, der E1-Wert ändert sich wie erwartet. Daraus ersehe ich, daß die mathematische Kopplung nicht aktiviert ist.

DECL E6POS Test1
DECL E6POS Test2
DECL E6POS Test3

Test1 = {X 630.08, Y -273.73, Z 30, A 0, B 0, C 0, E1 0}
Test2 = {X 630.08, Y -273.73, Z 30, A 0, B 0, C 0, E1 100}
Test3 = {X 630.08, Y -273.73, Z 30, A 0, B 0, C 0, E1 200}

LIN Test1
LIN Test2
LIN Test3

Bei mathematischer Kopplung müsste der Roboter doch die Bewegung der Linearachse "ausgleichen".

Meine Hauptfrage lautet damit: wie kann ich die mathematische Kopplung einschalten? In der KUKA-PDF-Anleitung steht zum manuellen Anschalten: Menüfolge "Konfiguration>Setze Werkzeug/Basis" wählen. Bei mir gibt es unter "Konfiguration" aber kein "Setze Werkzeug/Basis". Bei "Mathematische Kopplung über Programm aktivieren" steht: "Satzanwahl auf einen Bewegungssatz mit gekoppelter BASE der Kinematik durchführen". Was ist denn das und wie macht man das?

Für jede Hilfe wäre ich sehr dankbar!

Ciao,
Benjamin

Quote from Twister

Ebenso kannst du die Achse A4 und A6 auf "endlos drehen" konfigurieren?
($machine.dat)
$AXIS_TYPE[4]=5
$AXIS_TYPE[6]=5

Dieser Tip funktioniert. Zumindest in der Konstellation, die ich gerade ausprobiert habe, kann man so die Bahn zu Ende fahren. Allerdings treten genau die Schwierigkeiten auf, die du beschreibst. Man müßte sich hier also um Workarounds kümmern.

Für das Archiv: die aktuell vielversprechendste Lösung für mein Status-Turn-Softwareendschalterproblem ist es, Handachssingularitäten vorauszusagen und dann die Werkzeugorientierung auf der Bahn innerhalb der Toleranzen so weit zu ändern, daß die Singularitäten nicht mehr auftreten. Zur Vorhersage verwende ich die Orocos-Kinematics-and-Dynamics-Bibliothek (http://www.orocos.org). Das ist eine C++-Bibliothek, mit der ich die inverse Kinematik durchrechnen kann. Achtung: die Lösungen, die Orocos-KDL liefert, können sich von dem unterscheiden, was die KUKA-Steuerung macht. Falls während einer Bahn ein Vorzeichenwechsel an der A5-Achse auftritt, versuche ich, die Bahn manuell so zu modifizieren, daß der Vorzeichenwechsel vermieden wird. Bei den ersten Versuchen, hat das ganz gut funktioniert.

Quote from K(A)RL

Schau doch mal auf die Homepage: http://www.kuka.com
Da gibt es dann auch folgende weiteren Links:
KUKA Robotics = Roboterhersteller
KUKA Systems = Anlagenbau, der unter vielem anderen auch Konstruktionen, roboterbasierte Werkzeuge, und Fertigungseinheiten bis hin zu individuellen und flexiblen Fertigungslinien anbietet.

Ich habe auch bei KUKA Systems keinen solchen abgewinkelten Adapter gefunden. Oder meinst du, daß die (Ihr) das im Auftrag konstruieren?

Quote from BenjaminBihler

Und kann man diese kartesische Krümmung der PTP-Bahn in den Griff bekommen? Zum Beispiel, indem man die Bewegung zwischen zwei Punkten durch ganz viele Zwischenpunkte definiert? Oder konzentriert man damit nur die Krümmung, so daß bei einem solchen Zwischenschritt eine ganz große "Ausweich"bewegung stattfindet?

Fürs Archiv: ich habe es ausprobiert. Wie hustrac schon geschrieben hat, kriegt man "lineare" Bewegung durch A5=0-Stellungen einfach nicht hin, auch nicht durch Tricks. Wenn man ganz viele Zwischenpunkte mit gewünschtem Status und Turn setzt und diese mit PTP abfährt, dann passieren trotzdem "Ausweichbewegungen", falls die A5 das Vorzeichen wechselt. Es hat für mich sogar so ausgesehen, als wäre die Abweichung von der Linie noch größer, wenn ich viele Zwischenpunkte definiert habe.

Quote from BenjaminBihler

Gibt es so einen Adapter zu kaufen oder muß man da was selber basteln?

Fürs Archiv: zumindest von KUKA kriegt man sowas nicht. Also selber machen.

Quote from hustrac

Bei LIN -Bewegungen muß die A5 (wenigstens leicht) abgewinkelt sein .

Heißt das, daß ich diese Art von Problemstellen immer daran erkennen kann, daß die A5 im Laufe der Bahn das Vorzeichen wechselt?

Quote from hustrac

Hallo,

Nochmal!

Bei LIN -Bewegungen muß die A5 (wenigstens leicht) abgewinkelt sein .
Ansonsten geht es nicht.

Alternativ gibt es bei der KRC2 (neuerer Softwarestand) und bei der KRC4 die Möglichkeit LIN-Punkte als sogenannte Hand-PTP abzuteachen,hier spielt die Handachsen Singularität keine Rolle. Der TCP bleibt auf der Bahn ,es kann sich nur die Orientierung des TCP während der Fahrt leicht ändern.

Das klingt so ähnlich wie die Beschreibung von "$ORI_TYPE = #JOINT", die ich gerade in der Anleitung gefunden habe. Dazu steht hier "Während der Bahnbewegung wird die Orientierung des Werkzeugs kontinuierlich von der Anfangs- zur Endposition geändert. Dies geschieht durch lineare Überführung der Handachswinkel. Die Problematik der Handsingularität kann mit dieser Option vermieden werden, da keine Orientierungsführen durch Drehen und Schwenken um die Werkzeugstoßrichtung stattfindet."

Ist das dasselbe? Oder meintest du, daß man wirklich die Bahnpunkte teachen sollte?

Ich habe $ORI_TYPE = #JOINT mal ausprobiert. Da kam dann leider die Meldung "STOPP wegen Softwareendschalter +A3".

Quote from [wEm

link=topic=11188.msg53609#msg53609 date=1363260881]
Das Aufwickeln bekommst du mit Bahnbewegungen (LIN/CIRC...) nicht in den Griff. Entweder Du stellst Konstruktiv mit Deinem Tool sicher, dass A5 nicht in die Nähe der singularität kommt (daher sind Schweißbrenner auch abgewinkelt), oder Du fährst PTP mit dem Beigeschmack, dass er im Achsraum linear, im Kartesischen Raum eine gekrümmte Bahn fährt.

Und kann man diese kartesische Krümmung der PTP-Bahn in den Griff bekommen? Zum Beispiel, indem man die Bewegung zwischen zwei Punkten durch ganz viele Zwischenpunkte definiert? Oder konzentriert man damit nur die Krümmung, so daß bei einem solchen Zwischenschritt eine ganz große "Ausweich"bewegung stattfindet?

Quote from Roland Keller

An den Roboterflansch einfach einen Adapter konstruieren der 30° oder 45° abgewinkelt ist und dein Werkzeug daran befestigen.
Das löst in den meisten Fällen das Problem, da die Achse 5 dann meist eingeknickt ist.

Gibt es so einen Adapter zu kaufen oder muß man da was selber basteln?

Quote from Loelik

Dann kannst Du Positionen als FRAME deklarieren (ohne S und T), dann sollte es auch funktionieren.
Aber mit Vorsicht benutzen, wenn Du später diesen Punkt als PTP anfahren solltest, kommt es zu einer unvorhersehbaren Roboterbewegung. Kollisionsgefahr!!!

Ich habe die Antwort nicht ganz verstanden. Wir haben bei unseren POS-Deklarationen keine S- und T-Werte angegeben, da diese bei LIN-Bewegungen ja sowieso ignoriert werden. Eine solche POS-Angabe ist doch dann nichts anderes als eine FRAME-Deklaration.

Jedenfalls habe ich gerade versucht, die Bahnpunkte für die LIN-Bewegungen als FRAME zu deklarieren, aber das Ergebnis ist genau dasselbe: es kommt zu dem Aufwickeln, wenn ich die Punkte mit LIN-Bewegungen abfahre. Oder wie hast du das gemeint...?

Quote from Loelik

Hi,
wenn es möglich ist, würde ich aus dem LIN-Pinkten PTP rausmachen und die Funktion "kue_weg2" benutzen damit die S und T Werte berechnet werden.

Das klingt sehr spannend, aber ich bin mir nicht sicher, ob das klappt.

Ich habe mal folgendes probiert: die Positionen, an denen das Aufwickeln passiert, habe ich nicht mehr als POS über X, Y, Z, A, B, C vorgegeben, sondern als AXIS über A1 bis A6. Die Achswerte habe ich über unsere Software so berechnen lassen, daß dabei kein Turn-Wechsel auftritt. Vermutlich ist das Ergebnis dann dasselbe wie das, was kue_weg2 berechnen würde, oder? AXIS-Angaben kann man scheinbar leider nicht mit LIN-Bewegungen anfahren, also hab ich PTP-Bewegungen dafür genommen. Und tatsächlich findet das Aufwickeln nicht mehr statt. Die A4 dreht sich bei einer Bewegung relativ stark in eine Richtung, bei der nächsten Bewegung dreht sie sich aber wieder zurück, so daß die Stellung wieder die richtige ist.

Leider bewegt sich der TCP nicht mehr geradlinig, so wie bei den LIN-Bewegungen. Er "eiert" herum und zwar genau an einer Stelle, an der voraussichtlich ausschließlich geradlinige Bewegungen erlaubt wären (weil es sonst zu einer Kollision kommt).

Deshalb nochmals die Frage: wir würden gerne nur LIN-Bewegungen fahren. Einerseits, weil Freiheiten in der Bewegung zu Kollisionen führen könnten. Andererseits, weil wir PTP-Bewegungen (noch) nicht simulieren können. Muß man einfach einen Tod sterben? Also entweder mit LIN-Bewegungen aufwickeln oder mit PTP-Bewegungen gegen Kollisionen kämpfen? Oder gibt es noch eine andere Möglichkeit, ganz geradlinig zu fahren und trotzdem nicht aufzuwickeln?

Herzlichen Dank für die guten Antworten bisher und auch schon im Vorraus für diejenigen, die noch kommen.

Quote from IrrerPolterer

Was für ein A1 Problem hat er denn gemeldet? Das kann jedenfalls nichts mit der Singularität zu tun haben.

Die Fehlermeldung lautet "Unerreichbarer Punkt Softwareendschalter +A1". Ich habe die Meldung nicht verstanden, aber für die anderen Teilnehmer hier scheint das ja ein Begriff zu sein.

Quote from IrrerPolterer

Das Vermeiden solcher Probleme muss eigentlich schon in der Konstruktion berücksichtigt werden. Sprich die Position des Werkzeugs am Flansch sollte so angebracht sein, dass solche Verdrehungen nicht auftreten können.

Das klingt aber sehr kompliziert. Ich kann doch gar nicht wissen, wie ich das Werkzeug anders montieren soll, damit die Robotersteuerung keine solchen Aufwickelpfade berechnet, oder?

Hallo,

ich habe ein Problem beim Erzeugen von Programmen für einen KR100-2 HA mit Software V24.3.1/KUKA5.5.

Wir fahren mit LIN-Bewegungen entlang von Punkten, die wir aus einem CAD-Programm heraus generieren lassen. Es handelt sich im Großen und Ganzen um eine "Hin- und Herbewegung", so daß ich davon ausgehe, daß die Rückbewegung grundsätzlich immer möglich sein müßte, wenn die Hinbewegung möglich war.

In der Nähe von Singularitäten tritt es dabei aber relativ häufig auf, daß die A4 sich sehr weit in eine Richtung verdreht. Dabei ändert sich der Turn-Wert von 'B101010' auf 'B010011', der Status-Wert bleibt bei 'B010'. Anschließend kann der Roboter sich auf dem Rückweg noch ein Stückchen weit bewegen, unterbricht aber dann mit der Meldung "Software-Endschalter A4". Das Ziel dieser Bewegung ist dann mit der Stellung, die der Roboter eingenommen hat, nicht mehr erreichbar.

Manchmal funktioniert es, eine PTP-Bewegung einzubauen und für den Zielpunkt den Status- und Turnwert so anzugeben, wie er vor der Umgebung der Singularität war. Der Roboterarm eiert zwar dann ganz seltsam durch die Luft, kommt aber aus der Sackgassenstellung wieder heraus. Heute hatte ich allerdings einen Fall, bei dem das nicht funktioniert hat. Dort ist der Roboter während der PTP-Bewegung stehengeblieben und hat ein Problem mit der A1 gemeldet. Dies kann ich gar nicht verstehen, da die A1 etwa auf 0 war.

Deshalb meine Frage: wie kann man solche "Sackgassenprobleme" zuverlässig vorhersagen? Nur mit KUKA.Sim? Oder gibt es andere Kriterien, an denen man festmachen kann, ob der Roboter in eine Stellung hineinfährt, aus der er nicht mehr herauskommt?

Und mindestens genauso wichtig: wie kann man das vermeiden? Gibt es Tricks, die starke Verdrehung der A4 zu vermeiden? Muß man dazu unbedingt PTP-Bewegungen fahren? Wir würden LIN-Bewegungen bevorzugen, da wir dann im CAD besser abschätzen können, wie die Bahn genau verlaufen wird.

Für jeden Hinweis bin ich sehr dankbar!

Viele Grüße,
Benjamin