Beiträge von Sydekum-Automation

Guten Morgen zusammen,

ich habe ein Problem mit einer 7 Achse (Drehpositionierer) an der ein Werkstück befestigt ist.
Das Werkstück liegt horizontal vor dem Roboter und wird beim bearbeiten gedreht.
Auf dem Werkstück wurde eine Base vermessen (Base_Data[3]), da die zu bearbeitenden Punkte auf Vorder und Rückseite identisch sind.

Nun zu meinem Problem:
Wenn ich die 7 Achse um 180° drehe, ist meine Base Negativ. Der Roboter will also von der falschen Seite her anfahren.

ist es hier Sicherer/besser die Base_Data[3] zu manipulieren und mit +/- 180° zu berechnen oder die Tool_Data[5] entsprechend zu ändern?
Da das Werkstück an der 7 Achse befestigt ist, kenne ich durch den Drehwinkel E1 die aktuelle Ausrichtung und könnte bei Übergang von +180 -> +181° die Base_Data[3] / Tool_Data[5] immmer exakt bestimmen?!

Vielleicht kann mir am frühen morgen ja schon jemand einen Tipp geben, wie so etwas am Sinnvollsten und sichersten umgesetzt werden kann/sollte.

Roboter:
Roboter: KR120R2500 PRO C4 FLR
Version Steuerung: V8.3.320/KUKA8.3

Vielen Dank und einen gute Woche.

Gruss Pat

Wenn ich richtig verstehe, hat er vier identische Werkzeuge am Flansch, die jeweils um 90° versetzt sind, richtig?!
Also immer der gleiche TCP nur halt 90° in "A" gedreht.
Warum dann überhaupt rechnen? Es reicht doch aus, das richtige Tool vor Beginn des Abholens umzuschalten?!

Etwas mehr Informationen wären sinnvoll. Vielleicht sogar ein Archiv des Roboters?!
Wenn das nicht erwünscht ist, dann alle verwendeten Variablen auflisten bitte.
Gruss

moin moin,
ich denke das der SPLINE Block dann wohl eher nicht der Weg ist, den ich weiter verfolge.
Eine FOR Schleife habe ich ja aktuell bereits. Werde mich damit noch einmal in einer ruhigen Minute befassen.
Trotzdem danke allen Mitstreitern!
Gruss Pat

Hey Fubini,
vergiss was ich zuletzt mit der externen Achse geschrieben habe. Da war ich gedanklich nicht ganz bei der Sache
Das eine wie von dir als Beispiel genannte FOR Schleife nicht funktioniert konnte ich der Doku und dem Forum entnehmen.
Also habe ich eigentlich keine Möglichkeit, Daten aus einem Array mit variablen Anfang und Ende abzufahren?

hi fubini,
würde das mit dem SPL in der FOR Schleife klappen? Ich will nicht die ganzen Fahrbefehle die möglich wären abbilden, sondern ziehe mir die Daten aus der Struktur und fahre diese dann wie im letzten Beitrag gezeigt in der FOR Schleife ab.
Bisher hatte ich noch keine große Berührung mit den "S" Bewegungen. Hier nutze ich es, da ich die Extern Achse binden muss.

Kein Thema.
Im WoV gibt es bei aktiver Steuerung oben in der Leiste den Verschaltungseditor (zwei in sich verschlungene Pfeile). Mit diesem Kannst du die Signale so konfigurieren, wie du es benötigst.
Wenn du die EA Namen zugewiesen hast, ist es noch leichter damit zu arbeiten.

Hi,

also nur zur Info, ich nehme bereits Safe Operation Anwendungen in Betrieb und kenne daher die Möglichkeiten.
Mir geht es hier wirklich nur darum, wie ich eine solche Anwendung, wenn sie überhaupt sicher umsetzbar ist, gestalten könnte.

Ich bin mittlerweile der Meinung, das die "Kugeln" zur Absicherung des Werkzeugs nicht nicht exakt genug sind. Entweder sind sie zu groß, oder zu klein um die Verschiebung des nicht sicheren TCP´s abzufangen.
Ich muss also die Anzahl und Ausrichtung der möglichen Werkzeuge genau festlegen und entsprechene sichere Werkzeuge definieren. Diese gestalte ich dann so groß, das die von mir freigegebene max. TCP Änderung am nicht sicheren TCP die Kugel nicht überschreitet.
Der Kunde bekommt dann eine Tabelle mit den möglichen Werkzeugen und den max. zulässigen Änderungen des TCP´s.
Das ist dann zwar etwas mehr Aufwand, in der Vorbereitung für mich, aber aktuell sehe ich keine andere Möglichkeit es umzusetzen.

Die Auto Extern Schnittstelle ist standardmäßig belegt. Das steht ebenfalls in der Doku drin. Du kannst die Signale natürlich auf deine Bedürfnisse anpassen, aber wir lassen sie immer auf den Standard Werten.
guck mal hier https://www.roboterforum.de/ro…en/3230/msg13280#msg13280
Da ist eine Beschreibung der Signale mit entsprechender Beschaltung durch die SPS als Anhang.
Vielleicht hilft dir das weiter!?
Gruss
Pat

Moin zusammen,
ich habe hier ein Problem mit einer Bewegung, die Anhand einer selbstangelegten Datenstruktur ausgeführt werden soll.
Roboter: KR120R2500 PRO C4 FLR / V8.3.320/KUKA8.3
Die Datenstruktur wird von der KSS mit einer errechneten Bahn befüllt und soll im Anschluss abgefahren werden. Die Daten für die Berechnung der Bahn werden von der Leit SPS gesendet.
Wenn die Bahn berechnet ist, soll der Roboter in der Lage sein, die kompletten Punkte zusammen oder Teilstücke abfahren zu können.
Leider ist es so, das die Punkte sehr nah aneinander liegen müssen um die Bahn sauber abzubilden. Will ich nun jeden Punkte abfahren, kommt es zu Überschleiffehlern.
Der Fahrbefehl ist:
I=iStartpos (z.B: 506)
FOR I to iZaehler (z.B: 527)
SLIN xPos[I]
ENDFOR
dazugehörige Datenstruktur in der .dat:

Bewegung[506]={rPos_X 0.0,rPos_Z -87.5220413,rPos_Y -58.3800,rTCP_B -14.9560051,rAchse_E1 -156.295441}
Bewegung[507]={rPos_X 0.0,rPos_Z -87.9601517,rPos_Y -56.7119980,rTCP_B -14.4776649,rAchse_E1 -157.188248}
Bewegung[508]={rPos_X 0.0,rPos_Z -88.3834763,rPos_Y -55.0440,rTCP_B -14.0042725,rAchse_E1 -158.085922}
Bewegung[509]={rPos_X 0.0,rPos_Z -88.7922363,rPos_Y -53.3760,rTCP_B -13.5356035,rAchse_E1 -158.988510}
Bewegung[510]={rPos_X 0.0,rPos_Z -89.1866379,rPos_Y -51.7080,rTCP_B -13.0714312,rAchse_E1 -159.896}
Bewegung[511]={rPos_X 0.0,rPos_Z -89.5668564,rPos_Y -50.0400,rTCP_B -12.6115513,rAchse_E1 -160.808395}
Bewegung[512]={rPos_X 0.0,rPos_Z -89.9330902,rPos_Y -48.3719978,rTCP_B -12.1557541,rAchse_E1 -161.725677}
Bewegung[513]={rPos_X 0.0,rPos_Z -90.2854843,rPos_Y -46.7040,rTCP_B -11.7038527,rAchse_E1 -162.647812}
Bewegung[514]={rPos_X 0.0,rPos_Z -90.6242218,rPos_Y -45.0360,rTCP_B -11.2556524,rAchse_E1 -163.574768}
Bewegung[515]={rPos_X 0.0,rPos_Z -90.9494553,rPos_Y -43.3680,rTCP_B -10.8109732,rAchse_E1 -164.506500}
Bewegung[516]={rPos_X 0.0,rPos_Z -91.2613144,rPos_Y -41.7000,rTCP_B -10.3696404,rAchse_E1 -165.442932}
Bewegung[517]={rPos_X 0.0,rPos_Z -91.5599365,rPos_Y -40.0319977,rTCP_B -9.93148518,rAchse_E1 -166.384}
Bewegung[518]={rPos_X 0.0,rPos_Z -91.8454666,rPos_Y -38.3640,rTCP_B -9.49634361,rAchse_E1 -167.329620}
Bewegung[519]={rPos_X 0.0,rPos_Z -92.1180115,rPos_Y -36.6960,rTCP_B -9.06405830,rAchse_E1 -168.279709}
Bewegung[520]={rPos_X 0.0,rPos_Z -92.3776932,rPos_Y -35.0280,rTCP_B -8.63447189,rAchse_E1 -169.234146}
Bewegung[521]={rPos_X 0.0,rPos_Z -92.6246185,rPos_Y -33.3600,rTCP_B -8.20743752,rAchse_E1 -170.192841}
Bewegung[522]={rPos_X 0.0,rPos_Z -92.8588943,rPos_Y -31.6920,rTCP_B -7.78280592,rAchse_E1 -171.155640}
Bewegung[523]={rPos_X 0.0,rPos_Z -93.0806122,rPos_Y -30.0240,rTCP_B -7.36043882,rAchse_E1 -172.122421}
Bewegung[524]={rPos_X 0.0,rPos_Z -93.2898560,rPos_Y -28.3559990,rTCP_B -6.94019938,rAchse_E1 -173.093048}
Bewegung[525]={rPos_X 0.0,rPos_Z -93.4867172,rPos_Y -26.6880,rTCP_B -6.52195,rAchse_E1 -174.067352}
Bewegung[526]={rPos_X 0.0,rPos_Z -93.6712646,rPos_Y -25.0200,rTCP_B -6.10555840,rAchse_E1 -175.045166}
Bewegung[527]={rPos_X 0.0,rPos_Z -93.8435745,rPos_Y -23.3520,rTCP_B -5.69089842,rAchse_E1 -176.026352}
Wie kann ich alle Punkte in einer flüssigen Bewegung abfahren, ohne den Fehler zu bekommen. Alle Versuche mit verschleifen sind bisher gescheitert. Aktuell helfe ich mir damit, das ich nur jeden zweiten Punkt abfahre. Das führt aber zu Fehlern in der Qualität der Bahn.

Gruss
Pat

Was genau suchst du? Schon mit Workvisual gearbeitet? Gruss

Hallo SJX,
danke für deinen Beitrag. Das hatte ich mir schon fast gedacht! Der Bereich um das Werkzeug so groß wie nötig und so klein wie möglich zu gleich festzulegen. Das könnte dann Probleme mit den Zellenwänden geben... Aber ich kann ja auch einfach z.B: 4 sichere Werkzeuge definieren und dann je nach Tool_Data Daten das Werkzeug in diesem Bereich anwählen oder? So könnte ich den Sicherheitsbereich aufteilen und trotzdem immer ein sicheres Werkzeug welches mich im Prozess nicht einschränkt anwählen?!
Die Datenverwaltung der TCP´s kommt eh von der SPS, dann kann diese auch entsprechend das richtige Tool zur Ausrichtung schalten. Oder denke ich hier etwas zu einfach?

Hallo Robonator,
vielen Dank für deinen Beitrag. Die Wirksamkeit des TCP im Prozess, bzw. der Unterschied zum TCP der Safe Operation ist mir bekannt. Es geht mir lediglich darum, wie weit der TCP "manipuliert" werden kann/darf?
Hintergrund ist die Planung einer Anlage, an der der Bediener später selber Werkzeuge bauen und an den Roboter schrauben will. Diese werden kann mittels Struktur in die Tool_data geschrieben. Sprich neues Tool kann von dem Tool aus der Safety abweichen.
Ich überlege nun, ob ich bis zu einem gewissen Grad sage, das es zulässig ist und wenn die Abweichung zum Urspung zu groß ist eine Meldung und Stillstand generiere. Da sonst die Safe Daten nicht mehr zu dem TCP passen.
Vielleicht bringt diese Information mehr zum Thema?!

Gruss

Hallo zusammen,
ich habe mal eine Frage zu einem Thema, welches mich gerade beschäftigt.
Situation:

Ich habe einen eingemessenen Greifer mit sauberen TCP in der KRC4 hinterlegt und die Daten passen auch zu den Safe Operation Daten.
Jetzt möchte ich Prozesstechnisch den TCP im Programm verschieben um Abweichungen auszugleichen etc. Bis zu welchem Punkt meint ihr, ist es möglich die Korrektur vorzunehmen ohne die Safe Operation Daten zu verändern (was im Betrieb glaub ich eh nicht geht!?), oder den Bereich des Greifers größer zu definieren?
Gruss Pat

Hallo zusammen,
entschuldigt, das ich eine Weile nichts von mir hab hören lassen! Der Rest der Inbetriebnahme beim Kunden war noch sehr Zeitaufwändig.
Zum Problem: Wir hatten einen ABB Monteur vor Ort, der die Roboter mit dem Elektronischen Messgerät erneut vermessen hat. In allen Robotern war die dritte Achse zum Justagewert (Aufkleber) abweichend. Es wurde also ein Abgleich durchgeführt und ein neuer Aufkleber mit den neuen Daten am Arm befestigt.
Warum das bei allen Robotern der Fall war, konnte der Monteur nicht sagen. Die Vermutung liegt aber nahe, das beim Transport der Roboter über die dritte Achse gegurtet wurde und sich dadurch die Geber verstellt haben.
Nach den Änderungen, funktioniert das drehen um den TCP wieder. Allerdings habe ich auch hier bei einem Greifer mit einem mittleren Messfehler von unter 0,1, eine Abweichung von bis zu 1mm beim Drehen um Tool Z. Auch der ABB Monteur hat kein besseres Ergebnis hin bekommen und gemeint, das wäre schon sehr gut.
Da ich selten mit ABB arbeite, kann ich diese Aussage nur schwer nachvollziehen. Für meinen Teil bin ich etwas enttäuscht von der "Ungenauigkeit" der Roboter beim drehen um Tool-Z.
Vielen Dank für eure Unterstützung bei meinem Problem!

Hallo zusammen,

die Greiferdaten passen. Habe sie CAD technisch, händisch vermessen und durch die Werkzeugvermessung geprüft. Alle Verfahren sind bis auf wenige o,1mm identisch. Stoßrichtung passt auch soweit. Nur beim rotoerro um den TCP hält er hält nicht die Höhe und den Rotationspunkt.
Das holt mich im Ablauf ein, da ich beim Abholen um die Z Achse 45° drehe. Da sind dann teilweise 2mm Abweichungen vom eigentlichen Setz/Abholpunkt der Fall.
Was definitiv zu viel ist. Ich kann max. 0,5mm verkraften ohne zu kollidieren.
Habe auch schon nicht kalibriert, aber ohne Erfolg.

Umdrehungszähler sind aktualisiert. Programm ist neu geschrieben und eingerichtet.
Gruss

Hallo zusammen.
Ich habe das Problem, das mein Roboter IRB2600 nach vermessen der TCPs nicht sauber um diesen rotiert.
Ich habe den Greifer dreimal vermessen und jedes mal bis auf 0,01-0,03mm Abweichungen gehabt. Das Gewicht ist mit der Waage ermittelt und eingegeben wurden.
Trotzdem rotiert er beim Verfahren in EZ,EY und EX nicht sauber über der Spitze.
Bei verkuppeln um EX wandert der Punkt vor und zurück, bei EZ nach links und rechts und bei EY also um die eigene Achse dreht er, aber wandert dabei jeweils nach unten weg.

Was knnn das sein? Bei den anderen Greifer Greifern funktioniert es wie es soll?!
Gruss Pat

Hi Micky,
vielen Dank für die genaue Beschreibung der Funktion relTCP.
Ich habe nun ein bisschen damt gearbeitet und stolpere nun über ein neues Problem.
Im Anhang habe ich versucht es grafisch darzustellen und hoffe das verständlich ist, was mein Problem ist.
Ich drehe um Rx:=30.0 und erhalte eine neue Ausrichtung im Bezug auf den TCP, aber nun steht der Roboter nicht mehr senkrecht zur Base, sondern um 30.0° verdreht.

Gruss Pat

Das ist mir wie gesagt schon bekannt.
Ich nutze diese Funktion bereits in verschiedenen Programmen.
Ich muss das Tool aber auf Grund von mechanischen Änderungen um ca. 30° am Flansch drehen. Das heist alle Positionen wären falsch. Nun möchte ich einfach die Orientierung des Tools auf die mechanische Änderung anpassen.
Das sollte eigentlich gehen. Bei anderen Robotern geht's auch.