RELATIVE PTP or LIN BUT FROM A DATUM POINT

Lin_rel xp #Tool

Ptp_rel xp #Tool

Lin_rel xp #Base

...

Alternatively you can easily calculate the position using the : operator aka geometric operator. This has been explained many many times in the forum. Just use the search function for details:

Lin xp:shift

Lin shift:xp

Generally, using the Geometric Operator is considered superior to using #TOOL. I've been told (never tested it myself) that if _REL motion is interrupted (say, by an E-Stop) partway, when the robot resumes motion, it will begin the _REL motion over again from the robot's current physical position. So if a _REL motion of 100mm was stopped after only moving 50mm, then the robot was resumed, the actual motion would end up being 150mm.

Using the GeoOp to precalculate an absolute relative position avoids any such potential ambiguity.

Quote

Ive been told (never tested it myself) that if _REL motion is interrupted (say, by an E-Stop) partway, when the robot resumes motion, it will begin the _REL motion over again from the robot's current physical position.

Being quite familiar with the controller internals I seriously doubt this. Of course this behaviour would be the case if doing a line selection but not if you simply stop the robot using e.g. the stop button or when repositioning after an emergency stop.

But of course only working with absolute coordinates is also line selection safe.

agreed,

i have tested this exact scenario on few KSS versions and interrupted motion simply resumes...

but block select is a different story....

there could be an issue where EStop does cause a problem if during decel robot deviates from path or with certain other things such as trigger commands. i was asked to investigate and try to reproduce cases of collisions. in one of them problem was on certain KSS where TRIGGER or SYNC OUT instructions would be executed earlier than expected if EStop occurred. then as soon as EStop is resolved, tooling could move since output(s) state was changed by those instructions. So if you do have a palletizer or similar and gripper that is expected to move just before programmed pick point - you get a collision... or if you are almost there, gripper closes and shreds the product or itself.

but this is not due to REL motion, it is due TRIGGER evaluation that does not differentiate between deceleration to reach the end point and deceleration due to EStop.

the lesson is to always test program yourself at reduced speed and in different scenarios. don't assume anything. KUKA tries hard to keep things compatible but given complexity of KSS and number of releases, it is inevitable that something like this eventually slips though until it is noticed.

Read and understand Fubinis post.

MyPrel_Point:{x 30,y 0, z 0, a 0, b 0, c 0}

No #tool required/possible.

Once again: read fubinis post, he already explained it.

then you better let robot show you... perhaps do something like this:

PTP MyPrel_Point

PTP MyPrel_Point:{x 30,y 0, z 0, a 0, b 0, c 0}

PTP MyPrel_Point

PTP MyPrel_Point:{x 0,y 30, z 0, a 0, b 0, c 0}

PTP MyPrel_Point

PTP MyPrel_Point:{x 0,y 0, z 30, a 0, b 0, c 0}

PTP MyPrel_Point

PTP MyPrel_Point:{x 0,y 0, z 0, a 30, b 0, c 0}

PTP MyPrel_Point

PTP MyPrel_Point:{x 0,y 0, z 0, a 0, b 30, c 0}

PTP MyPrel_Point

PTP MyPrel_Point:{x 0,y 0, z 0, a 0, b 0, c 30}

Sorry, but am I writing Suaheli or any other language? I know my english is not the very best, but in this case I think there is no doubt about it.

You asked

Quote from IlFincoITA

In a LIN_REL I'll write LIN_REL {X 30} #TOOL but this point is relative to the actual position. I want to do the same thing but making a motion that is relative to "MyPrel_Point" is it possible?

I answered:

Quote from hermann

MyPrel_Point:{x 30,y 0, z 0, a 0, b 0, c 0}

What do You think does this mean?

of course this is relative to tool. If you want to have a position relative to base you write

{x 30,y 0, z 0, a 0, b 0, c 0}:MyPrel_Point

and if you want to have a moving instruction relative to base you write

LIN {x 30,y 0, z 0, a 0, b 0, c 0}:MyPrel_Point

And by the way, there is one more possibility: Just try it out on a robot or in the simulation, instead of asking for every little detail.

or use forum search which as mentioned before with keyword geometric Operator and e.g the following among many others explaining this comes up

Re: Shift before reaching the specific point