Beiträge von Eagle

Erstmal danke an alle für die Antworten...

Tja wie soll ichs sagen, das Problem hat sich gelöst, fragt mich nicht wie.

Meine Vermutung ist, dass er die Befehlszeile $BASE=BASE_DATA[4] nicht ausgeführt hat oder so... Ist euch sowas schonmal vorgekommen?
Die Koordinaten können in BASE[4] Koordinaten angefahren werden, anscheinend hat "er" noch die WORLD-Koordinaten verwandt und nach diesen konnte er den Punkt nicht erreichen.

Als Ergänzung: Den Punkt hatte ich von Hand angefahren und geteached. Im Programm wird er mit LIN angefahren...
Naja, vielleicht hab ich auch aus Versehen erstmal die Zeile $BASE=BASE_DATA[4] als Kommentar rausgenommen... Ist die einzige logische Lösung, auf die ich komme...

Hallo zusammen!

Mein Kuka KR30 L16, seine KR C2 Steuerung und ich haben mal wieder eine Meinungsdifferenz bzw. Verständigungsprobleme.

Habe heute eine neue BASE definiert (3 Punkt Verfahren) und möchte nun anhand dieser BASE ein Programm laufen lassen. Die Punktkoordinaten sind alle auf die neue BASE bezogen und ich setze auch
$BASE=BASE_DATA[4]

So, nun meldet der gute Junge "Arbeitsraumfehler", wenn ich den Punkt (X 0, Y 0, Z 0) anfahren möchte. Dieser Punkt liegt an einer Tischkante, aber mit einem kleinen Sicherheitsabstand, habe ja den BASE-Nullpunkt da hingelegt.

Von Hand konnte ich den Punkt ja problemlos anfahren und in der Custom.dat im Steu-Ordner sind keine Arbeitsräume definiert. Somit frag ich mich, woher er einen Arbeitsraumfehler hat, wenn ich doch eigentlich keine Arbeitsraumüberwachung aktiviert habe ?!?

Seh ich da was falsch? Wo kann ich feststellen, ob überaupt ein Arbeitsraum überwacht wird?

Kann ich von Hand einen Arbeitsraum verletzen, im Programm aber wird abgebrochen?

Bin nur ein kleiner HiWi und hier ist keiner, der richtig Ahnung davon hat...

Um die Stimmung hier mal was zu lockern und zu zeigen, wie der Roboter klingt...

etwa so:

http://www01.zkm.de/robotlab/v…/instrument_480x360_h.mov :ylsuper:

Soviel dazu, scheint also ein normales Geräusch zu sein.

Wünsche erstmal ein schönes Wochenende!

Sooo, der HiWi hat mal wieder Fragen und Probleme

(Roboter: KR30L16, KR C2)

Ich möchte gerne folgendes machen:

Ich möchte meinem Roboter, der mit einer schönen Schweißpistole ausgestattet ist, gerne Positionen beibringen, ohne diese zu teachen. Die Positionen werden von einem externen Programm erstellt (bzw. sollen erstellt werden).

Die Schweißpistole hat einen Krümmungswinkel von 45°. Nun würde ich gerne eine Orientierungsnullage bestimmen, bei der die Schweißpistole exakt senkrecht nach unten zeigt. Aus welcher Himmelsrichtung die Pistole kommt, ist hierbei egal.

Nun möchte ich gerne verschiedene Punkte anfahren, von denen mir aber nur die Koordinaten X,Y und Z im Raum gegeben sind. Zu diesen Punkten gehört dann eine bestimmte Orientierung, wie zum Beispiel "45° Neigung um die X Achse nach rechts" und "30° Neigung um die Y-Achse nach hinten".
Eventuell auch noch aus welcher Himmelsrichtung die Schweißpistole kommen darf, um Kollisionen zu vermeiden.

Wie kann ich jetzt Punkte deklarieren, damit der Roboter die Position X,Y,Z anfährt, dort dann die Orientierung (30° stechendes Schweißen für eine Bewegung in positiver X-Richtung und 45° Neigung nach rechts) hat und zusätzlich noch die Pistole um die Schweißdraht-Achse ausgerichtet ist?

Mein Problem liegt also daran, dass ich irgendwie die Information (30° stechend schweißen) in A,B und C Koordinaten umrechnen muss und zusätzlich über die Singularität angeben muss, auf welche Art und Weise er diese Position erreichen darf. Leider kann ich für jede Position die nötigen T und S Werte nur durch das tatsächliche Anfahren der Positionen herausfinden. Ich muss diese aber möglichst vorher schon wissen. Ohne korrekte Werte wickelt sich der Roboter die Drahtführung um den Hals, weil er statt 10° nach rechts zu drehen, sich lieber entscheidet um 350° nach links zu drehen, argh.

Kann ich hier mit INVERS oder FORWARD etwas erreichen?

Ich muss doch irgendwie vorher bestimmen können:
- Position X,Y,Z
- Schweißpistole zeigt (immer vom Roboter aus in positive X-Richtung geblickt) 45° nach links unten und zeigt 30° nach vorne
- Später: Roboterarm muss rechts stehen

Das alles, ohne Positionen zu teachen...

Martin: Ok, werde vielleicht (aber gaaanz vorsichtig) mal probieren.

WolfHenk: Jooo, ich weiß ja, dass es ne Simulation ist, aber auch die hat schon Sollgeschwindigkeit bemängelt...
Es geht mir darum, dass Sollgeschwindigkeit, Sollgetriebemoment Fehler auftreten, wenn ich den Override teilweise auf 1% habe...

Habe hier ein Programm vorliegen, dass mit 150 einzelnen LIN-Bewegeungen, die gerade mal 10mm lang sind zwei Schweißbahnen (gerade!) abfährt.
Hat wohl was damit zu tun, dass unser Robi noch keine Splines kann und das Programm von einer anderen Steuerung kam... egal, darum gehts ja nicht.
Die Sache ist die, dass dieses Programm in der Simulation mit Override 30% und exakt den gleichen Geschw. und Beschl. Parametern läuft.
In der guten alten Realität gibts dann an einzelnen Stellen Probleme. Erstmal schaltet die Achse A4 ab, wegen Sollgeschwindigkeit und ja, er hat sich in dem Moment auch schnell drehen müssen (Override 10%). Aber wenn ich dann weiterfahren möchte (Fehler quittieren, Override auf 1% stellen...), dann zuckt der Robi kurz für 5mm und steht dann sofort wieder...
Von Hand kann ich die Achse problemlos weiterdrehen. Meine Vermutung war jetzt, dass die Schmierung durch die sehr geringe Aktivität des Roboters nicht optimal ist und durch die erhöhte Reibung ein zu hohes Getriebemoment entsteht. Ein Indiz dafür wäre dann zum Beispiel dieses surrende Geräuscht, wenn die Achse A4 dreht (muss garnicht mal so schnell sein).

Naja, ich bin nur HiWi und wundere mich eben, warum der große 700kg Roboter bei Bewegungen Probleme kriegt, die nicht mal andeutungsweise den Geschwindigkeiten einer Produktionskette in einem Automobilwerk entsprechen. Dort huschen und tanzen die Robis unglaublich schnell durch die Gegend, haben 15kg schwere Werkzeuge vorne dran und ich kann nicht mal ein kleines Häuschen vom Nikolaus in die Luft zeichnen, ohne dass der Roboter irgendwelche Sollwerte überschreitet.

Klar, kann ich dem ganzen entgehen, wenn ich die Punkte anders teache und versuche, immer einen Winkel über 5° in der Achse 5 zu haben, aber bei dem Projekt an dem ich arbeite, gehts vor allem darum, berechnete Punkte anzufahren, keine geteachten. Ein Schweißteil steht schön gerade vor dem Roboter und der muss dann eben die LIN-Wege einhalten. Dann kommt es automatisch dazu, dass die Achse A5 meist gerade ist, weshalb die Achse A4 sich nen Wolf tanzen muss.

Naja, wenn ich mit LIN einer Schweißnaht entlangfahre, dann muss ich die Position und Orientierung einhalten...

Mir gehts ja auch primär darum, dass die Simulation klappt und die Realität nicht mal ansatzweise...
Macht eure Achse A4 so ein Surr-Geräusch, wenn sie schneller drehen soll?

Achse A5 ist gerade nach vorne, also nicht angewinkelt...

Hallo zusammen,

ich sitze hier am Kuka KR 30 L16 mit KR C2 Steuerung.

Des öffteren habe ich schon die Vermutung gehabt, dass an der Achse A4 des Roboters irgendetwas nicht stimmt.
Programme, die in der Simulation mit Kuka Sim Pro mit den selben Geschwindigkeits- und Beschleunigungswerten auf 30% Override laufen, machen am tatsächlichen Roboter schon bei 10%, ja teilweise sogar bei 1% Override Probleme.

Ich vermute, dass die Achse A4 (der Roboter läuft vielleicht 1h pro Woche, wenns hochkommt) entweder irgendwo schleift, die Bremsen nicht komplett geöffnet sind, oder die Schmierung aufgrund der langen Standzeit nicht ausreichend ist. Der Roboter wird nur gelegentlich für Testzwecke bewegt.

Bei vielen Bewegungen, z.B. bei kurzen LIN-Strecken muss die Achse A4 sich sehr schnell drehen, um die Bahntreue zu gewährleisten. Bei dieser Drehung macht die Achse ein surrendes Geräusch, leider weiß ich nicht, wie ich das Geräusch richtig beschreiben soll. Es ist ein surrendes/pfeifendes Geräusch, wie wenn man einen E-Motor von Hand dreht.

Daher meine Frage an euch: Hat jemand Erfahrung mit diesem Robotermodell oder einem ähnlichen und kann mir bestätigen, dass dieses Geräusch "normal" für die Achse A4 ist? Habt ihr auch ständig Probleme mit Sollgeschwindigkeit bzw. Sollgetriebemoment, auch wenn im Modus T2 bei 10% Override verfahren wird?

Hier mal die Werte aus der config.dat:

DEF_VEL_PTP=100
DEF_ACC_PTP=50

DEF_VEL_CP=1.0
DEF_VEL_ORI1=50.0
DEF_VEL_ORI2=50.0
DEF_ACC_CP=2.29999995
DEF_ACC_ORI1=100.0
DEF_ACC_ORI1=100.0
DEF_VEL_FACT=1.0

An diesen Werten kann es denk ich mal nicht liegen...

Super dankeschön...

Also eine ArcTech Software ist auf den Roboter schon installiert. Inwiefern die auf unsere Schweißanlage und den geplanten Betrieb schon konfiguriert ist, kann ich leider noch nicht sagen. Mal schaun, wenn die Schweißanlage endlich angeschlossen wird.
Je nachdem, ob ich dann noch eine Einleitung bekomme, kann ich mich ja nochmal melden oder bei der genannten Nummer anrufen.

THX

Hallo zusammen!

Eagle hat mal wieder eine Frage...

Es geht darum, dass demnächst an den KR 30 L16 eine Schweißanlage angeschlossen wird. Da ich als HiWi mich bisher nur "von Hand" in das Thema "Roboter Programmieren" eingearbeitet habe, weiß ich natürlich nicht, wie das mit dem Schweißen so abläuft.

Die Schweißanlage wird über mehrere Ein- und Ausgänge mit der Steuerung verbunden, nehme ich an.
Kann mir jemand einen kleinen Crashkurs geben, wie ein Programm zum Schweißen aussieht?

Vereinfacht würde ich mir das jetzt so vorstellen, dass ich neben meinen Bewegungssätzen dann noch die Prozess-Sätze dazuschreibe...
Diese Prozesse laufen dann parallel zu den Bewegungssätzen ab?!?

LIN P1
Schweißen an (delay 1sek) ==> Ausgang xybla auf 1 setzen?
CIRC P2 P3
Schweißen aus...

Irgendwie so. Wie sieht das wirklich aus? Hätte gerne eine Vorstellung davon, wie der Schweißvorgang gesteuert wird. Man braucht ja viele Parameter (Schweißdrahtvorschub etc...)

Danke schonmal für alle, die sich die Zeit nehmen.

Würde mich auch mal interessieren das Tool

Ok danke.
Dachte halt es wäre ein Fehler, dass 2 Achsen zusammenfallen hierbei, weil ich bisher gedacht habe, dass alle 3 Achsen verdreht werden... Naja, werde deinem Ratschlag mal folgen und dann muss ich die Position mal anders anfahren.

Zitat

Wie schon vorher gesagt es wird immer um die gedrehten Achsen weitergedreht, daher ist die Reihenfolge der Drehungen entscheidend (zuerst Z dann die gedrehte Y dann die gedrehte X). Wird dann um die X-Achse gedreht entsteht quasi die selbe Drehung wie um die ALTE Z-Achse, nur in die andere Richtung.

Hier liegt genau mein Problem... Die Reihenfolge ist in diesem Moment nicht mehr entscheidend...

LIN {a 0,b 90,c 0} ;Ausgangsposition
> LIN {c -90} ==> Drehung um alte Z-Achse

oder

LIN {a 0,b 90,c 0} ;Ausgangsposition
> LIN {a 90} ==> Drehung um alte Z-Achse

liefern das gleiche Ergebnis. Aus der Position mit a=0, b=90, c=90 kann ich mit einer LIN Bewegung keine Rotation um die alte X-Achse (neue Z Achse)erzeugen.
Reihenfolge: b=90 dreht das Koordinatensystem um y. x-Achse schaut jetzt also quasi nach unten. Wenn ich jetzt im Winkel a ODER c fahre, dann dreht sich beidemale das Tool um die alte Z-Achse (neue X-Achse). Wieder Winkel b dreht das Tool auch wieder um die alte und neue Y-Achse. Weder a noch b noch c ergeben eine Drehung um die alte X Achse (neue Z-Achse). Nach b=90 liegen X- und Z-Achse parallel. Ich habe kein Dreibein mehr...

Ist das korrekt? Wenn ich dich richtig verstehe, dann bleibt die Z-Achse immer konstant, aber X- und Y-Achse können sich verändern? Dann wäre es ja tatsächlich unmöglich aus einer Ausgangsposition wie A=0, B=90, C=0 oder A=0, B=-90, C=0 das Tool um die originale X-Achse zu drehen. Irgendwie schmeckt mir das garnicht.

Hm könnte sein, erklärt aber nicht, warum die bei b=90 die Beziehung a=-c gilt...
Egal zu welcher Basis ich die Bewegungen durchführe, a, b und c sind doch immer senkrecht aufeinander und somit ist a=-c in meinen Augen unmöglich. Dann wären ja X-Achse und Z-Achse identisch!?!

Ochje, hoffe dein Arm erholt sich schnell wieder

Mein Problem ist an der Stelle

LIN {a 0,b 90,c 0}
LIN {a 0,b 90,c -90}

Von der ersten auf die zweite Bewegung müsste doch eine Drehung erfolgen. Laut meiner Vorstellung von Winkel c müsste diese Drehung um die X Achse sein. Wenn ich von Hand C in negativer Richtung Drehe kommt auch genau die Drehung, die ich erwarte. Wenn ich aber LIN {c -90} mache kommt die gleiche Drehung wie wenn ich LIN {a 90} machen würde?
Warum ist da ein Unterschied zwischen Handfahren und T2 Programmfahrt?

Auffällig sind auch die eingeblendeten Istwerte der Koordinaten.

Während des Drehvorgangs springt der C Wert auf -100er Werte (von 0 aus).
Sobald ich die Bewegung anhalte springt der C Wert zurück auf z.B. -24.
Der Wert a ist IMMER GENAU 0.000000, das passt doch nicht...

Hiho zusammen.

Mein Robi verwirrt mich im Moment mit seiner Orientierung.

Ich probiere gerade ein wenig mit dem Orientierungsverhalten meines Robis rum (KR 30 L16 mit KR C2)

z.B.:

LIN {a 0,b 90,c 0} ;Hier "schaut" meine Schweißpistole senkrecht nach unten
LIN {a 0,b 90,c -90} ;Hier dreht sich die Pistole um die Z-Achse??? Drehung um X Achse erwartet
LIN {a 90,b 90, c 0} ;Hier bewegt sich der Robi nicht, die Orientierung scheint identisch zu sein.

Bisher habe ich immer gemeint, in kartesischen Koordinaten bewirken die Achsen a,b,c folgendes:

a --> Drehung um Z-Achse
b --> Drehung um Y-Achse
c --> Drehung um X-Achse

Wenn ich von LIN{a 0,b 90,c 0} ausgehend von Hand den Winkel C Verfahre, dann dreht sich das Tool um die X Achse. Bei der LIN Bewegung allerdings dreht er sich um die Z-Achse und macht exakt die gleiche Bewegung wie bei Drehung um Winkel a.

Versteh ich nicht, in meinen Augen sind die Orientierungen {a 0,b 90,c -90} und {a 90,b90,c 0} nicht gleich...
Bin ich da in einen Spezialfall geraten, bei dem dann noch s bzw. t Wert gesetzt werden müssten???

Ich habe sie bisher nur in der config.dat geändert. In den madas stehen die maximal zulässigen Werte.

Habe die Werte von meinem Robi mal auf max gesetzt, als ich so schnell wie möglich um eine 90° Ecke huschen wollte mit 90° Orientierungsänderung. Allerdings muss man dann aufpassen, dass bei Automatikbetrieb schnell die Sollgeschwindigkeiten überschritten werden können. Muss man halt testen und schön langsam rantasten!

Dafür gibts auch die Funktion C_Vel, dann wird überschliffen, wenn eine bestimmte Geschwindigkeit unterschritten wird.

Beispiel

$APO.CVEL=90

bedeutet, dass das Überschleifen dann beginnt, wenn die Geschwindigkeit unter 90% fällt (Abbremsen vor Punkten).

Bei 100% sollte er normalerweise dann mit konstanter Geschwindigkeit weiterfahren. Ob das beim Hilfspunkt der CIRC Bewegung hilft, weiß ich allerdings nicht, diese sollte normal auch mit konstanter Geschwindigkeit abgefahren werden.

Ändert sich die Orientierung während der Bewegung? Oft liegt das Problem an den zu niedrigen Ori-Geschwindigkeiten oder Beschleunigungen.

Ach ich glaub ich habs selber gefunden, Überschleifen beginnt ja frühestens auf der hälfte der Strecke.
Überschleifen gleich von anfang an ist nicht möglich oder?

Ich habe mir für den Kuka KR30L16 mit KR C2 Steuerung ein paar Unterprogramme geschrieben, um Bewegungen in der XY-Hauptebene schneller programmieren zu können. Sie arbeiten jeweils mit LIN_REL oder CIRC_REL.

Mein Problem bezieht sich nun auf folgenden Programmausschnitt.
m_hoch fährt den Robi in Z-Achse hoch und mit minus runter.
m_dreh_y dreht um die Y-Achse.
m_vor fährt den Robi entlang der X-Achse.
Das CHAR als zweiter Parameter dient in einer Switch-Anweisung jeweils als Parameter für den Überschleifmodus und der letzte Parameter ist für den Überschleifweg etc. gedacht.

Ausgerichtet wird das Tool (Schweißpistole) vorher so, dass sie etwa 60mm über der Schweißbahn senkrecht nach unten steht. Um mein Unterprogramm m_dreh_y zu testen, wollte ich nun den Robi runterfahren lassen und die Schweißpistole im 30° Winkel nach vorne "stechen" lassen --> Stechendes Schweißen...

Habe verschiedene Überschleifmodi gewählt, hätte es gerne so, dass der Robi die Schweißpistole bereits auf dem Weg nach "unten" dreht, daher Überschleifen mit C_DIS 50 oder eben C_VEL 100, aber der Bewegungssatz in m_dreh_y wird erst durchgeführt, wenn m_hoch abgeschlossen ist...

Zwischen m_hoch und m_vor klappt das Überschleifen prima, aber mit der Umorientierung von m_dreh_y klappts nicht wirklich. Habt ihr da vielleicht ne Idee?

Hauptprogramm:
...
m_hoch(-50,"v",100)
m_dreh_y(-30,"o",5)
m_vor(1000,"n",0)
...

;FOLD m_hoch
GLOBAL DEF m_hoch(height:IN,cont:IN,value:IN)
REAL height,value
CHAR cont
FRAME ZP
ZP=$NULLFRAME
ZP.Z=height

SWITCH cont
CASE "d","D"
$APO.CDIS=value
LIN_REL ZP C_DIS
CASE "v","V"
$APO.CVEL=value
LIN_REL ZP C_VEL
CASE "o","O"
$APO.CORI=value
LIN_REL ZP C_ORI
DEFAULT
LIN_REL ZP
ENDSWITCH

END
;ENDFOLD

;FOLD m_dreh_y
GLOBAL DEF m_dreh_y(winkel:IN,cont:IN,value:IN)
REAL winkel, value
CHAR cont
FRAME ZP
ZP=$NULLFRAME
ZP.B=winkel

SWITCH cont
CASE "d","D"
$APO.CDIS=value
LIN_REL ZP C_DIS
CASE "v","V"
$APO.CVEL=value
LIN_REL ZP C_VEL
CASE "o","O"
$APO.CORI=value
LIN_REL ZP C_ORI
DEFAULT
LIN_REL ZP
ENDSWITCH
END
;ENDFOLD

;FOLD m_vor
GLOBAL DEF m_vor(length:IN,cont:IN,value:IN)
REAL length, value
CHAR cont
FRAME ZP
ZP=$NULLFRAME
ZP.X=length

SWITCH cont
CASE "d","D"
$APO.CDIS=value
LIN_REL ZP C_DIS
CASE "v","V"
$APO.CVEL=value
LIN_REL ZP C_VEL
CASE "o","O"
$APO.CORI=value
LIN_REL ZP C_ORI
DEFAULT
LIN_REL ZP
ENDSWITCH

END
;ENDFOLD