Constrain TCP in B and C movement due to singularities at axis 4. Tool is not allowed to be tilted in axis B and C doing movement, but direct SLIN movement causes singularities.

No solution but a few remarks:

Quote from ChristianLiinHansen

The manual was also referring to that using REL could be potential bad, because if the robot program is somehow interrupted, the robot do not know where it is, and therefore e.g. REL A5 180 degree could lead to that the axis 5 will self-collide, because the robot just start moving axis 5 180 degree and dont take into account the absolute angle.

Only after line selction. A type of interaction is something you definitly do not want in the production process. Restarting after stop without line selection changes nothing because the path planner is not triggered again.

Quote from ChristianLiinHansen

So is there a way to make a SPTP movement, but with constrains on B and C movement of TCP?

Probably not since this contradicts how PTPs work in general. PTP is a axis type motion moving initial axis values to desired target axis values. These axis start/target values are the result of the backward trafo of your programmed initial and target position (mostly for convieneience programmed in cartesian space). Since in a standard 6 axis kuka bot every axis is rotational obvioulsly each axis moves the TCP on a circular path. Circluar paths are not linear and therfore orientation can not be kept constant. Compared to linear moves like SLIN there is no forced cartesian condition on path shape. And this forced condition on path shape is one of the main reasons why there are singularities at all.

My suggestion: Can you use SLIN with $ORI_TYPE = #JOINT? This keeps axis 1 to 3 on the linear path and orientation is handled by running A4 to A6 PTP. This usually brings only small deviations in orientation compared to $ORI_TYPE not equal #JOINT?

Quote from ChristianLiinHansen

hen made a new position, but when the robot controller executes the program, the singularities still occurred with SLIN. Using SPTP the robot started to tilt the tool.

This suggests you have a status problem. Since the PTP always tries to reach its programmed status you could probably improve this behaviour by choosing the correct status of axis 5 which shoul be just flipping the hand status bit.

Fubini

Quote from ChristianLiinHansen

- I can not just use SPTP after I have lifted up the fork tool, because this will make the tool starting to tilt in B and C axis (robot controller most optimum path), which will however tilt whatever the robot is carrying with the tool, and this will risk that I will drop the objects on the floor.
- If I simply just juse SLIN, I will encounter the singularities in axis 4, i.e the robots TCP stands still while axis 4 rotates a lot.

Does this need to be a single motion? Off the cuff, what I would usually do in a real-world situation like this would be to teach a LIN move up to near the singularity, then a PTP through the singularity, followed by more LINs. If the PTP motion is small enough (and the S&T variables aren't somehow incorrect), and C_PTP and C_DIS are used, the motion should look almost like a continuous linear move.

Quote from ChristianLiinHansen

- What I consulting in the manual, was that I could use REL for axis 5. This works in jogging mode, i.e. I came through the singularity simply by increasing angle of axis 5, but I tried teaching a position just before singularity, then jogged axis 5 till I it was OK, then made a new position, but when the robot controller executes the program, the singularities still occurred with SLIN.

REL motions are generally not advised.

Any LIN or SLIN motion that tries to drive A5 through 0 will result in a singularity error. That is why I suggested the LIN-PTP-LIN sequence above.

If the wrist moves oddly for the PTP motion, then something may be wrong with your S&T settings on the points before and after the PTP move. One way to check this would be to program the PTP move with an E6AXIS point instead of E6POS, and see if that fixes the issue.

Quote from SkyeFire

teach a LIN move up to near the singularity, then a PTP through the singularity, followed by more LINs. If the PTP motion is small enough

That's exactly what OriType=Joint in mode Autoorijoint does for you in Spline moves. Difference is only it assures additionally that a1 to a3 follow Cartesian path exactly and only a4 to a6 cheat slightly in orientation. So one should stay closer to linear reference path.

Unfortunately I do not remember the exact system variables to activate this mode. It's been too long that I have seen a real controller.

$ORI_TYPE, I think? I've never used it, but one of the BAS subroutines sets it.

Has #VAR, #JOINT, and #CONSTANT as possible settings. Defaults to #VAR most of the time.

There is another variable modifying the mode behind ORI_TYPE joint with Spline. That's the one I forgot about. Something like “autoorijoint“ . If this is not set orItype joint in Spline behaves like old motion oritype joint: the orientation is cheated for the whole motion. In the other mode only a short orijoint is substituted in close to singularities. Hence most parts of the motion do not cheat orientation.

Quote from Fubini

$SPL_ORI_JOINT_AUTO = #ON/#OFF thats the one

Hm! That variable doesn't show up in any of my system backups (up through KSS 8.5.8), or my KUKA docs.

Would not be the first time nobody bothered to add it to documentation. Since I no longer have access to any KUKA software can someone verify that it exists. I think the variable is not in any config files but a real time system internal system variable. Same as e.g. $BASE.

If you are only passing in the vicinity of the singularity and not straight through you can change $CP_VEL_TYPE to #VAR_ALL. This would work if overspeed is the issue.

Quote from Fubini

$SPL_ORI_JOINT_AUTO = #ON/#OFF that's the one

interesting tidbit, thank you for that. just for sake of completeness, i checked on KSS8.5.8, and compiler accepts that variable name and values #ON/#OFF