Teachpunkte berechnen

Schau dir mal die Befehle Ptp_rel und Lin_Rel
in der Expertendoku Seite 83 und Seite 70 an.
Ich denke das suchst du.

Referenzpunkt Teachen und mit Lin_rel die anderen Punkte in z anfahren.
Auf Base und Tool achten.

Du kannst folgendes machen:

Teache nur einen Referenzpunkt, und berechne alle anderen Punkte vom Referenzpunkt aus gesehen.

Die Berechunung hast du ja schon:

Zitat von freelancer77

VP1 ist 30 mm in Z über NP
VP2 ist 30 mm in Z über ZP

ZP - NP = 95,4 mm

Und Achtung:

Zitat von hmi_visu

Auf Base und Tool achten.

Wichtig!

Hallo
Von den Relativbewegungen würde ich mal abraten. Und zwar weil diese Bewegungen nach einer Unterbrechung wieder neu gestartet werden. D.h. du willst zum Beispiel 200mm fahren. Nach 100mm wird die Fahrt unterbrochen. z.B. durch wegnahme der Fahrfreigabe. Kommt die Freigabe dann wieder, so wird die Bewegung nicht einfach fortgesetzt sondern neu gestartet. In diesem Beispiel versucht der Roboter dann also 300mm zu fahren. Das kann manchmal böse aua machen.

Für solche Fällen teachen wir uns einen Punkt und mit diesem berechnen wir dann die anderen. Das geht z.B. mit Pos.x= Pos.x+200.
Eine andere Möglichkeit ist über die Baseverschiebung zu gehen (siehe Handbuch).

mfg
Olaf

Zitat von OHuuck

Und zwar weil diese Bewegungen nach einer Unterbrechung wieder neu gestartet werden. D.h. du willst zum Beispiel 200mm fahren. Nach 100mm wird die Fahrt unterbrochen. z.B. durch wegnahme der Fahrfreigabe. Kommt die Freigabe dann wieder, so wird die Bewegung nicht einfach fortgesetzt sondern neu gestartet. I

Das ist definitiv nicht richtig! Die Bewegung wird fortgesetzt - nicht neu begonnen. Lediglich, bei einer Satzanwahl, würde die Bewegung neu gestartet, was ja logisch ist.

Sorry, aber meine persönlichen Erfahrungen und die mehrerer Kollegen haben genau das von mir beschriebene Verhalten gezeigt.
Wir haben dabei den Roboter über die Automatik-Extern von einer SPS aus gesteuert. Während einer Relativbewegung kam es zu einer Störung auf Seiten der SPS. Diese hat die Fahrfreigabe für den Roboter weggenommen. Nachdem die Fahrfreigabe wieder gesetzt wurde wollte der Roboter noch einmal den kompletten Weg der Relativbewegung fahren.
Ich will allerdings nicht ausschliessen, dass KUKA hier inzwischen nachgebessert hat. Die Erfahrung habe ich bereits vor einigen Jahren gemacht und seither den Einsatz von Relativbewegungen so weit wie möglich vermieden.

Hallo,
die Relativbewegungen sind beim Anfahren eines Punktes eh nicht
zu gebrauchen.
Das ginge nur beim Wegfahren vom Punkt, das 'Zum Punkt Hinfahren'
muss auf jeden Fall berechnet werden.
LIN_Rel bezieht sich immer auf die aktuelle Position, und nie auf die,
die noch kommen soll.

Hermann

Hallo,
meine Erfahrung hat auch gezeigt, dass eine Lin_Rel-Bewegung von der aktuellen Position ausgeführt wird. D.h. dass ein gestoppter Roboter wieder die ganze Bewegung durchführen würde (wobei ich auch nur mit älteren Kukas (KRC1) arbeite).

Aber mit der Berechnung von OHuuck müsstest du auf jeden Fall auf der sicheren Seite stehen.

Gruß Markus

Zitat von GreenH

meine Erfahrung hat auch gezeigt, dass eine Lin_Rel-Bewegung von der aktuellen Position ausgeführt wird.

Zitat von OHuuck

Sorry, aber meine persönlichen Erfahrungen und die mehrerer Kollegen haben genau das von mir beschriebene Verhalten gezeigt.

Wenn dies wirklich der Fall wäre, würden REL-Bewegung keinen Sinn ergeben. Ich arbeite ständig damit und solche beschriebenen Fehler sind bei mir nie vorgekommen. Ich werde das aber natürlich noch mal checken.

Zitat von IrrerPolterer

Wenn dies wirklich der Fall wäre, würden REL-Bewegung keinen Sinn ergeben. Ich arbeite ständig damit und solche beschriebenen Fehler sind bei mir nie vorgekommen. Ich werde das aber natürlich noch mal checken.

Nicht immer, aber passiert ist mir das auch schon!
Vor allem mit dem 3er und 4er Softwarestand!

Ich bleibe dabei - mir ist's noch nie passiert und ich werd's weiter benutzen.

hmm wenn du von einer vorhängig unbekannten Position wegfahren willst (und das nicht zu einem bekannten Punkt) dann schreib doch einfach die aktuelle Position in eine temporäre Variable und fahre relativ zu dieser Variable mit dem goemetrischen Operator. (Aber Achtung mit dem Vorlaufzeiger!!!!)
Das würde auch bei einer erneuten Satzanwahl keine Probleme geben.

Wenn die Mechanik i.O. ist würde ich mir die X, Y und Z Parameter berechenen. und diese dann in der Bewegung verwenden und anschließend auf meine zu fahrende Position rechnen oder nur zuweisen, kommt aber immer auf den Bereich an ob sich dabei die Achskonfig ändern kann. Der KUKA ist dabei nicht so einfach wie der ABB oder FANUC.
Wenn aber die Mechanik durch aus ein Problem der Genauigkeit machen kann nehme ich immer gern Datenfelder für so etwas.

z.B.:
FRAME P1[n] ; muss keine FRAME sein kannst jede beliebe Positionsart dafür verwenden.
P1[1]={X -766.799988,Y 432.679993,Z -81.6900024,A -138.720001,B 85.9300003,C -62.1899986}
P1[2]={X -807.659973,Y 416.619995,Z -78.6100006,A -109.650002,B 83.5699997,C -28.4699993}
P1[3]={X -813.530029,Y 415.459991,Z -76.7099991,A -106.93,B 82.7900009,C -21.0799999}
.
.
P1[n]={X -813.530029,Y 415.459991,Z -76.7099991,A -106.93,B 82.7900009,C -21.0799999}

Das kannst Du dann problemlos über einen Zähler aufrufen. In etwa so:

nAblagepos=2 ; Zähler welchen Du vorher in der Logik ab Deine abzulegende Position anpasst.

LIN (P21_PQ46_2WD[nAblagepos]:{X 0, Y 0, Z 50.0, A 0, B 0, C 0}) C_DIS ; bei einer Bewegung zum Toolkoordinatensystem
oder
LIN ({X 0, Y 0, Z 50.0, A 0, B 0, C 0}:P21_PQ46_2WD[nAblagepos]) C_DIS ; bei einer Bewegung zum Basekoordinatensystem

anschließend anfahren der Endpos

LIN P21_PQ46_2WD[nAblagepos] C_DIS

Hat den Vorteil das Du jede Position flexibel beeinflussen kannst. Wie gesagt nutze ich wenn die Jungs von der Konstruktion wieder einmal die Toleranzen großzügig vergeben haben. Is ja billiger.

Teachen geht eigentlich auch ganz easy Variable ändern Punkt einrichten teachen. Kommt nun darauf an wie viele Punkte Du hast.

Hoffe Dir etwas geholfen zu haben.

Sven