Exist a shift function for an entire block?

The function SHIFT applies only for one point. Also you can take a look over the DECOMPOSE and TRANS function.

Alexandru is correct regarding SHIFT function, it is applicable for one location reference only.

However, you can:

- LMOVE (SHIFT xxxxx BY x,y,z) instead of moving to defined location.

You can also create location arrays, then by using FOR/END loop, use the loop variable to set the array element/index.

Below just creates 10 locations from a master location with an 'X' distance of 50mm between each point.

Points are tst[1] - tst[10]

  FOR .tmp = 1 TO 10 STEP 1
    POINT tst[.tmp] = SHIFT(mst_tst BY ((.tmp-1)*50),.y,.z)
  END;

In addition to this you could also have the LMOVE in the place of the POINT as below and not create ANY other locations.

  FOR .tmp = 1 TO 10 STEP 1
    LMOVE SHIFT(mst_tst BY ((.tmp-1)*50),.y,.z)
    STABLE 0.1;
  END;

I'm very curious about this.....in the case of CAM generated program you 'll have a thousands of line made by thousands lmove, example:

.PROGRAM test()
BASE uframe1
TOOL t1
LMOVE TRANS(....)
....
....
....
LMOVE TRANS(....)
.END

In this case the SHIFT approach is useless, what about a new TOOL definition in the middle of program?

In the begin I have a Tool t1 defined as

.TRANS

t1 0.0 0.0 100.0 0.0 0.0 0.0

.END

If I change the definition in tool 0.0 0.0 99.0 0.0 0.0 0.0 will I have a shift in z direction?

Quote from Motouser

If I change the definition in tool 0.0 0.0 99.0 0.0 0.0 0.0 will I have a shift in z direction?

You will not SHIFT, you will TRANS along the Z axis of the Tool.

You are making the tool shorter, so the arm posture will slightly change given for the same transformation positions taught.

If your tool Z vector is parallel with Z vector of your BASE, it would appear to shift, but the tcp will be at the same location as it would be with (0,0,100,0,0,0), just the arm will be in a slightly different posture.

So no SHIFT.

Make sense?

Quote from kwakisaki

So no SHIFT.

Make sense?

Unfortunately make sense!

The thing that confuse me is the existence(in motoman language) of an instruction called SETTOOL: here you can redefine the tool calibration without doing a calibration (like tha AS tool instruction). It's used to recover a program after a crash/deformation of the TCP.

I use it in particular way: I redefine the lenght of the tcp for a milling process so the tool of program remain the same but if I use another drill I simply adjust the lenght.

So in the end: in the case of CAM-generated program we must get back on the computer and recreate it with the right measurement.

Quote from Motouser

So in the end: in the case of CAM-generated program we must get back on the computer and recreate it with the right measurement.

No not at all.

Don't forget, when you are moving to a stored location or via stipulated coordinates then these coordinate values are where the robot is intended on moving the TCP to.

If you are changing the tool coordinate mid program and the new coordinate is longer or shorter, then the motion will reflect this.

- if the tool coordinate is longer than the physical tool, then the physical TCP will be further from target.

- if the tool coordinate is shorter than the physical tool, then the physical TCP will be closer to target.

For instance, if I am running a test routine, and want to employ a safety distance, I simply make a tool adjustment by:

TOOL test_tool+TRANS(0,0,10,0,0,0).

However, I very rarely do any tool command changing mid program, unless it is a tool changing operation, but I handle that differently.

In CAM, there are numerous ways that motions can be expressed and they do shoot for TRANS instructions and any approach/depart motions should include a Z element change in the TRANS coordinates, which may look like a SHIFT, but it is not applied relative to BASE, but the TCP position instead, so as I was saying earlier, if the Z base and Z tool axis are parallel, it will 'appear' like it's shifted (SHIFT is relative to BASE), but actually it is along the Z axis of the TCP.

Quote from kwakisaki

- if the tool coordinate is longer than the physical tool, then the physical TCP will be further from target.

- if the tool coordinate is shorter than the physical tool, then the physical TCP will be closer to target.

I was editing my old comment while you are answering:

that's why it will maybe work, I'm just fooling the real/physical tool.

Quote from kwakisaki

In CAM, there are numerous ways that motions can be expressed and they do shoot for TRANS instructions and any approach/depart motions should include a Z element change in the TRANS coordinates, which may look like a SHIFT, but it is not applied relative to BASE, but the TCP position instead, so as I was saying earlier, if the Z base and Z tool axis are parallel, it will 'appear' like it's shifted (SHIFT is relative to BASE), but actually it is along the Z axis of the TCP.

It's exactly what I need...the post is indeed about a SHIFT in BASE..but I'm more interested in a shift in TOOL coordinates

Quote from Motouser

that's why it will maybe work, I'm just fooling the real/physical tool.

It will work as you intend

Not that I'm experienced with CAM stuff, but you should see Z element variations in the TRANS command, which relates to TCP position relative to base/frame/workpiece.

Quote from kwakisaki

It will work as you intend

Not that I'm experienced with CAM stuff, but you should see Z element variations in the TRANS command, which relates to TCP position relative to base/frame/workpiece.

As you maybe remeber, my first kawasaki test project was about a certain strange application. Then I move to another one and keep this project aside.

Unfortunately I don't have a real robot free to test, I can simply simulate it in my CAM environment....but try to understand me....I prefer the real world.

Poor @Marco Antonio Asselta I'm messing all his post

Quote from Motouser

As you maybe remeber

Ha.......that's a challenge in itself.

Quote from Motouser

Poor Marco Antonio Asselta I'm messing all his post

Just need to make sure they don't get confused over your use of SHIFT comments, you are not shifting in the programmatical sense.