What’s the simplest way to do step and repeat for a moderate length program? Right now, I have a fixture with four positions lined up in a row with each position set up as a plane. We program on Position one and change planes to do the others. However, we’re experiencing some issues and want to eliminate the planes.
The palleting wizard seems to be geared more towards…palleting…and not much else. Plus from what I remember, it’s not geared towards having a large program tree within it.
I’m wondering if introducing an offset to the TCP would work, essentially make the robot think the TCP is in a different spot and it moves accordingly.
A bit more info on your application and what issues you’re having would help us.
I don’t think program size will affect the pallet nodes. And pallets can be used for as little as 4 parts (maybe even 2 but I haven’t tried). Setting up a pallet for parts aligned in a row would probably work very well.
I have pallets that hold over 150 parts during CNC machine tending in programs with several hundred nodes and don’t really have problems related to size except the occasional slowing down of the TP, but that only happens every few months at most and a reboot solves it.
Let us know a bit more info on what you’re doing and the issues and these guys will get you going in the right direction.
The use of a feature to move a set of motions to different locations is exactly what it is designed to do. This should be the most effective solution. You may want to explore the reasons this is not working well for you before trying other options.
Another option would be to make all of your waypoints relative waypoints after moving to an initial fixed waypoint. That way your activities could be a subroutine of all relative waypoints that is repeated in 4 locations. This is basically what a pallet sequence does. Which explains why you would have trouble adding a lot of motion commands in a pallet sequence unless you made them all relative waypoints.
Adding an offset to the TCP could have unintended consequences depending what kinds of commands you are performing. If you were to work in force mode for instance, the force is to be applied at the TCP which can cause strange behavior if the TCP is not actually where the force is being applied.
For some reason, the waypoints on the plane shift slightly, up to 1/8", which causes the glue to miss the parts that it’s supposed to. When I check the plane definition, everything is spot on. So it seems as if there’s some sort of math error being introduced somewhere. My thought was to use alternate methods to reduce as many variable as possible. Problem is it’s kind of intermittent, I can’t get it to repeat (or change really) so I can figure out where the error is coming from.
For fixtures that are rotational, I was planning on having the base set as a variable and change the rotation of it.
For fixtures that are linear, I was thinking about changing the TCP. We don’t use force or anything like that.
we also have a plane aplication with TIG-welding (acruacy requierd -+0.1mm) and a NC code. somtimes spot on somtimes terribel. I found out that where I teach the plane (X+,Y+ and lenght to orgin) need to be spot on! if I teach the pane in the right X+/Y+ but the distance to the orgin is different, the aplication would fail. Engravig Orgin,X+ and Y+ in a mold solves the problem. Also I need to have the tool constant in the same orientation otherwise it will fail too.
Use function trans_pose(get_actual_tcp_pose,P[offsetX,offsetY,offsetZ,offsetRX,offsetRY,offsetRZ]
(split it apart, the order matter!!!)
I would break down the problem into two parts.
The first part is whether the robot is mathematically going to where you want it to go.
To check this part, I would put a break point after it moves to the desired waypoint, and go to the move tab and look at the position of the robot relative to your plane. The robot position should agree with the position you programmed.
The second part is whether the robot is physically where you want it.
If the robot is not physically at the distance you want, then either your robot TCP is off, your plane definition is off, or your robot calibration is off. Any of these three things will yield to error in actual position.
When you define a plane, you should define the long end of the plane as the X-axis. The y-axis is only used to tilt the plane and actually doesn’t need to be perpendicular to the origin and x plane, you want to use a point as far off from the origin as possible in the y direction.