Relativ Bewegung.

Das in den geschweiften Klammern ist eine Struktur (in dem Falle wohl Frame). Man kann auf diese Art keine Strukturelemente ersetzen.
Versuch's so:

FRAME meinframe
REAL X_pos

X_pos=irgendwas
...

meinframe=$NULLFRAME ;Vorbelegung, damit alles 0 wird
meinframe.x=X_pos
...
Lin Rel meinframe
...

Hallo Leute,

ich habe ähnliches vor und bin beim stöbern im Forum und mit etwas Eigenschmalz auf so eine Lösung gekommen. Ich habe das noch nicht ausprobieren können, daher meine Frage: würde das auch gehen? falls nicht warum?

real offset

offset=100

PTP Home
PTP p1
p2=p1
p2.X = p2.X+offset ;neuen p2 berechnen
PTP p2 ;den in x um 100 verschobenen punkt p2 anfahren
...

Kann es sein das ich noch den p2 als Frame deklarieren muss?

Vielleicht kann uns ja jemand weiterhelfen

viele Grüße Rüdiger

Ja, klar geht das. Ist ja sozusagen dasselbe, nur ohne Relativbewegung.
p2 sollte formal denselben Datentyp haben wie p1, damit es rund wird. (Wenn p1 eine Pos ist, dann also p2 auch als POS deklarieren.)
(Wobei ich persönlich ein besseres Gefühl hätte dabei:
"
p2=p1
p2.X = p1.X+offset ;neuen p2 berechnen
"
und zwar deshalb, weil man beim schrittweisen Verfahren mit Umsetzen des Programmzeigers bei Deiner Lösung den Offset beliebig aufaddiert, wenn man nicht hoch genug springt.)

Und das Ganze geht natürlich NICHT, wenn p1 als AXIS oder E6AXIS deklariert wurde....

ah okay ich verstehe.

das heißt nun, wenn der p1 mit Inlineformular angelegt und geteacht wurde, gehts so net.

dann muss ich den p1 mit Xp1 aufrufen.

Der p1 aus dem Inlineformular müßte doch als E6Pos Xp1 deklariert sein. Demnach muss/sollte mein p2 auch als E6Pos deklariert werden, und nicht als Frame.

stimmt das alles soweit?

Grüße Rüdiger

Prinzipiell richtig.

Allerdings habe ich Dir vorhin verschwiegen, dass der Kuka mit der automatischen Typumwandlung in diesem Fall ganz gut klarkommt. Das heisst: Du könntest die Variable p2 durchaus als Frame deklarieren, in der Anweisung
p2=xp1 wird dann der Rest rausgeschnitten. Schön ist das nicht und im Sinne der reinen Lehre, aber es funktioniert.

Gelegentlich muss man sogar absichtlich auf diese Effekte spekulieren: wenn Du den P2 z. B. als PTP anfahren wolltest (oder müsstest), dann hättest Du Status und Turn mit drin, aber ohne zu wissen, ob der Roboter überhaupt bei der Offset-Position noch dieselbe Konfiguration halten kann. In dem Falle wäre der Frame sogar die vernünftigere Lösung. Bei LIN-Bewegungen wird S und T sowieso ignoriert, wenn Du dann auch keine externen Achsen hast, ist es eh egal.

Auf die Inline-Formulare würde ich bei solchen Sachen lieber verzichten, besonders für direkt nachfolgende Punkte. Base- und Tooleinstellung lassen sich bei der Programmierung über die Inline-Formulare im Fold beliebig verstellen, wenn man dann aus einer solchen Bewegung anhält, mit der Absicht "nochmal probieren", und dann den Programmzeiger auf die "nackte" Bewegungsanweisung setzt, sind u. U. schon andere Tool, Base und Geschwindigkeiten eingestellt, ohne dass man es richtig sehen kann. Das gibt unschöne Überraschungen, für Bediener mit Halbwissen sowieso, aber auch unsereins vergißt sowas mal im Stress...

Grüße,
Michael

Hey Michael,

ja cool, vielen Dank für die wertvollen Infos.

Ist echt ein klasse Forum hier.

bis zur nächsten Frage

Gruß Rüdiger

kann ich auch einen Wert abziehen?
p2.x=p2.x -diff_1

ja.

Aber ich würde empfehlen, bei solchen Sachen immer den "Doppelpunktoperator" (siehe Forumssuche) zu verwenden. Nur so hast Du auch im Fall dass Dein Ziel evtl. irgendwann mal rotiert auch die Gewissheit, dass es passt...