Hallo,
die Anleitung von wetzelaer gilt nicht für deine KRC4, sondern für KRC2. Bei KRC 4 musst du es über folgende Funktionen (Achtung Link ins englische Forum!)
http://www.robot-forum.com/rob…n-krc4/msg38078/#msg38078
machen.
Gruß,
Fubini
Hallo,
die Anleitung von wetzelaer gilt nicht für deine KRC4, sondern für KRC2. Bei KRC 4 musst du es über folgende Funktionen (Achtung Link ins englische Forum!)
http://www.robot-forum.com/rob…n-krc4/msg38078/#msg38078
machen.
Gruß,
Fubini
Hallo Damson,
die Basenamen stehen doch in der $config.dat unter
DECL CHAR BASE_NAME[32,24]
BASE_NAME[1,]="Flansch_an_R2"
BASE_NAME[2,]=" "
BASE_NAME[3,]=" "
BASE_NAME[4,]=" "
BASE_NAME[5,]=" "
...
Insbesondere kannst du also den Basenamen direkt in KRL lesen. Somit könntest du doch einfach deinen String der Reihe nach gegen die in BASE_NAME[,] vergleichen (siehe StrComp). Die gesuchte Basenummer ist dann einfach der BASE_NAME[]-Index bei dem der Vergleich nicht schief geht.
Fubini
Hallo RainerH,
für Verschiebungen sollte man immer den Doppelpunktoperator ":" (manchmal auch geometrischer Operator genannt) verwenden. Sonst wirds spätestens wenn noch Orientierungen dazu kommen nicht mehr richtig. Aber das nur am Rande. Zu deinem eigentlichen Problem: Ist der Roboter sauber justiert?
Fubini
Hallo,
zur Orientierungsführung über Drehen und Schwenken:
angenommen das Roboterforum macht eine gemeinsame virtuelle Flugreise von "München" nach "New York", dann entspricht "München" der Startorientierung und "New York" der Zielorientierung. Auf einer 2 dimensionalen Weltkarte kann man das auch über die beiden Werte für Längen- und Breitengrad ausdrücken, d.h. man muss Startlängengrad und Startbreitengrad bei München in Ziellängengrad und Zielbreitengrad bei New York überführen. Insbesondere braucht es nur zwei Freiheitsgrade um die Orientierungen ineinander überzuführen.
Geht man dann wieder ins dreidimensionale dann wird aus der Weltkarte ein Globus und Start sowie Zielorientierung sind einfach Punkte auf der Kugeloberfläche. Alle möglichen anderen Orientierungen liegen dann auch wieder auf der Kugeloberfläche. Stellt man sich nun vor man zeigt mit dem Finger auf "München", dann ist die Frage wie muss ich den Globus unter meinem Finger wegdrehen um auf "New York" zu zeigen. Insbesondere kann mann dann die notwendige Änderung im "Breitengrad" als "Schwenken" bezeichnen und die Änderung im "Längengrad" als "Drehen".
Jetzt ist noch die Frage wo spukt hier die ausgezeichnte Werkzeugstossrichtung "x" rein. Das ist aber auch ganz einfach, dass ist nämlich die Verbindungsgerade von einem "Ort" auf der Kugeloberfläche zum Kugelmittelpunkt. Hält man dann gedanklich die Verbindungsgerade im Kugelmittelpunkt fest, dann entspricht eine Bewegung der Verbindungsgeraden auf der Kugeloberfläche entlang eines Längengrads gerade dem "Drehen" und eine Bewegung der Verbindungsgeraden auf der Kugeloberfläche entlang eines Breitengrads dem "Schwenken".
Als letztes möchte ich noch die Frage zur Eulersingularität mit einer Gegenfrage beantworten: Welchen Längen- und Breitengrad haben Nord- und Südpol? Man sieht da wird es etwas schwammig.
Das hatte jetzt alles noch nichts direkt mit den A,B und C Winkeln zu tun, sondern die Orientierungsdarstellung über "Drehen" und "Schwenken" bzw. Längen- und Breitengrad ist nichts anderes als eine andere Form um Orientierungen im Raum darzustellen.
Fubini
Hallo,
von mir nur eine Antwort und ohne Gewähr, d.h. ich wage nicht zu entscheiden ob es bei dir zulässig ist den Bremsentest zu deaktivieren:
http://www.roboterforum.de/rob…entest/msg58417/#msg58417
Fubini
Hallo,
das geht leider nicht, da der Override zum Bewegungsausführungszeitpunkt wirkt, während der Ruck bereits von der Bewegungsplanung eingerechnet wird. Ich weis nicht mehr wer, aber irgendjemand hat hier mal den schönen Vergleich angestellt, dass der Override sowas ist wie der Lautstärkeregler an einerStereoanlage. Wird ein Lied abgespielt ist es bereits vollständig inklusive aller Lautstärken in Relation zueinander fertig aufgenommen (geplant) und durch das Abspielen (Ausführung) kann nur noch das ganze komplett skaliert werden.
Fubini
Hallo,
du solltest dir im klaren sein, das verschiedene Eulerwinkel Triple die gleiche Orientierung darstellen. In Wirklichkeit sind die Eulerwinkel nur eine einfache Darstellung einer orthonormalen 3x3 Orientierungsmatrix über drei Parameter, d.h. verschiedene Werte von A,B und C führen (u.a. wegen den dahinterliegenden Sinusen und Cosinusen) zum gleichen Ergebnis:
http://www.roboterforum.de/rob…erator/msg13666/#msg13666
Insbesondere bei B ungefähr +90 oder -90 bekommst du es noch zusätzlich mit der Eulersingularität (im Englischen auch gerne als Gimbal-Lock bezeichnet) zu tun. In diesem Fall sind A und C nicht mehr eindeutig sondern nur deren Summe. Das ganze ist schon zigmal hier im Forum diskutiert worden, so dass du über die Stichwortsuche mit "Eulersingularität", "Eulerwinkel", "homogene Koordinaten" einges finden solltest.
Ferner solltest du dir mal anschauen wie der KUKA die Orientierungsführung macht. Die eigentlich drei vorhandenen Freiheitsgrade werden nämlich auf zwei reduziert (Drehen und Schwenken, daher immer die ORI1 und ORI2 in z.B. $VEL und $ACC). Das ist möglich weil man immer um eine feste Koordinaten Achse dreht und schwenkt, wobei bei KUKA die ausgezeichnete feste Achse die x-Achse des Werkzeugkoordinatensystems ist (Hinweis: für Spline gilt das so nicht mehr!). Das steht auch meines Wissens nach so in der Doku.
Fubini
Hallo Grubba,
bei der KRC4 gibt es meines Wissens nach $RAISE_TIME[] in der R1/$machine.dat nicht mehr. Du musst stattdessen auf RampUpTimeUnderLoad in E<n>.xml schauen (n aus {1,...6} je nachdem welche Achse deine Asynchrone Zusatzachse ist).
Fubini
Hallo MSTEP,
ja das kann sein bedingt durch den längeren Hebel der Achse 3. Hast du denn mal die R1/$machine.dat und die $Robcor.dat gegeneinander verglichen. Was sind dann die Unterschiede? Bei meiner V5.6 habe ich z.B. unterschiedliche Achshochlaufzeiten $RAISE_TIME[] gefunden, d.h. die Achsen beschleunigen anders. Was jetzt bei deiner KSS Version die genauen Unterschiede sind kannst du am besten selber durch einen Diff entscheiden.
Fubini
Hallo,
schau mal nach CONST_VEL im Link unten oder in der Doku.
http://www.robot-forum.com/rob…vement/msg63188/#msg63188
Fubini
Justage schon geprüft? Base schief eingemessen? Armverlängerung verbaut?
Fubini
Normalerweise liegt nach der Installation der komplette Maschinendaten-Baum auf der D Partition. Dort musst du nur die passende Maschine finden und dann entweder bei laufender Steuerung über die KUKA-Oberfläche im Expertenmodus über die "falsche" drüberkopieren. Fallst die Steuerung nicht läuft kannst du das auch dierekt über den Windows-Explorer machen. Und wie du gerade gelernt hast ist wichtig: Vor Änderungen bitte vorher immer sichern und archivieren!!!
Fubini
Hallo pat,
die schnelle Antwort ist, dass KUKA selbst keine DH-Parameter außer für die kinematische Beschreibung der Hand benutzt. Die lange Antwort dazu findest du im englischen Partnerforum:
http://www.robot-forum.com/rob…7-r800/msg62365/#msg62365
Fubini
Hallo,
PTP VorKarton C_PTP C_DIS
LIN Vorpunkt C_DIS
und
PTP VorKarton C_PTP
LIN Vorpunkt C_DIS
sind absolut das gleiche, da auf CP-Seite C_DIS immer der Default ist. Mischen von Kriterien ist auch möglich, so dass es auch nicht daran liegen kann, dass du von C_PTP aud C_DIS wechselst.
Ist der Roboter absolutgenau? Findet ein Lastwechsel zwischen den Punkten statt? Funktioniert das Überschleifen in T2 bei kleinem Override? Gibt es zusätzliche Meldungen, falls du $STOPNOAPROX aktivierst und das Programm dann in T2 abfährst? Müssen auf CP-Seite irgendwelche Achsen reversieren?
http://www.roboterforum.de/rob…en/9644/msg46291#msg46291
http://www.roboterforum.de/rob…oglich/msg21924/#msg21924
Fubini
Hallo,
in der Anzeige siehst du nichts anderes als den Wert von $POS_ACT und das ist das $Tool bezüglich $Base. Wenn du was anderes willst kannst du es selbst über den Doppelpunkt-Operator aus $POS_ACT herrechnen. Siehe z.B.:
http://www.robot-forum.com/rob…-point/msg29249/#msg29249
Fubini
Hallo,
also meine Empfehlung wäre auch CONST_VEL im Splineblock zu verwenden:
http://www.robot-forum.com/rob…line-continuous-movement/
Fubini
Zitatwas ich persönlich immer noch nicht verstehe wieso das standardmässig von Kuka so gegeben ist
Das kommt noch aus Zeiten als man Industrieroboter nur über achsspezifische PTP-Bewegungen steuern konnte und das somit noch keine Rolle spielte. Im Laufe der Zeit haben sich die Leute dann einfach daran gewöhnt. Würde man das jetzt noch ändern würden einen die ganzen alten Hasen wohl dafür steinigen weil man nicht mehr abwärtskompatibel ist. Zugegeben jeder der neu anfangt denkt sich natürlich was für ein Sch... .
Fubini
Zitatdass er mir jetzt die A4 beginnt zu drehen,
Wenn die Achse 4 unerwartet viel dreht ist das meist ein Zeichen für die Alpha-5-Singularität. Kann es sein das der Achse 5 Winkel nahezu Null ist, wenn die A4 soviel dreht?
ZitatKann mir momentan nicht vorstellen das ich so effizient programmieren kann, wenn ich jedesmal noch die einzelnen Bit's für S und T setzen muss
Normalerweise erreicht man das gewünschte Verhalten am leichtesten in dem man noch Zwischenpunkte auf dem Weg vom Start zum Zielpunkt setzt. Ansonsten programmiert man ja meistens über Inlineformulare und die setzen Status und Turn immer mit.
Hast du dabei auch Status und Turn der kartesischen Zielposition beachtet? Ohne Turn fährt der Roboter immer auf kürzesten Achsweg vom Start zum Zielpunkt und muss dabei eventuell über einen Endschalter drüber. Wahrscheinlich ist der Punkt nur über den langen Achsweg einer Achse erreichbar und im Handverfahren bist du über den langen Weg zu dem Punkt gelangt. Bei (achsspezifischen) Relativbewegungen spielt das keine Rolle solange weniger als 180 Grad programmiert sind.
http://www.robot-forum.com/rob…-(-s-)/msg33654/#msg33654
Fubini
Hallo,
ZitatHabe mal kurz Versucht ein im OrangeEdit erstellte Routine auf die KRC4 zu laden und auszuführen, doch beim ersten Bewegungssatz läuft der Robi mir in einen Softwareendschalter, obwohl er sich keinen Millimeter von der Home-Position bewegt hat.
Das ist normal sofern du eine PTP-Bewegung programmiert hast. Liegt die Zielposition deiner programmierten Bewegung hinter den Softwareendschaltern fährt der Roboter gar nicht erst los.
Fubini