Using Variables in Cell.src

Hi
Go to monitor> Variable> Signal> type "$softp_end[4]". this will show the software limit setting in the positive direction for A4 (for example current value is 180 change new value to 185). You can modify value if you require, just be sure that it is before the physical hard stops.

you can then repeat this for $softn_end[4] for the axis travel in the negative direction A4 (for example if current value is -20 change new value to - 180). And just change the number inside the bracket for other axis. May be this helps

@Capitain:
Are you sure, that extension of axis limits is good advice, especially A4? Robot can cut cables inside or damage other parts of A4 axis. This is the worse thing you can do, if you want to avoid singularities.

bwait:
You can declare AXIS or E6AXIS variable and write something like this:
E6AXIS TEMP_POS

For A1 axis:
TEMP_POS=$AXIS_ACT
IF $AXIS_ACT_MEAS.A1 >= 170 THEN
TEMP_POS.A1=167
ENDIF

PTP TEMP_POS

If you write something like this, you will program movement inside your limits.
Don't expand your limits more, than you have in robot documentation, if you don't want to have mechanical and/or electrical problems with your mechanical unit.

And one more thing. Cell.src is not runing continously and you can't avoid singularities and movements outside of limits in this way. Cell.src is normally selecting program to run, and when other program is running, your "rules" will not be executed. You have to avoid wrong positions during planning and programming your motions, not during program execution.

If the issue is wrist singularities, opening up the A4 and A6 soft-limits won't fix the problem -- it will merely let the axes get further before they fault. The real fix is, don't make motions through the singularity.

Tecnically, A4 and A6 should (on most robots) be physically capable of endless rotation -- they have no hard stops. However, this can definitely create issues with any end-effector cabling that crosses over the wrist from the A3-A4 link to the A6 mounting flange.

As Animisiewaz already pointed out, you can create an E6AXIS variable, modify it, then use that variable in a PTP command.
Basically, motion commands (PTP, LIN, etc) cannot accept hard-coded Structures that contain variables inside the curly braces {}. So:

DECL E6AXIS MultiAxisVariable
DECL REAL SingleAxisPosition
SingleAxisPosition=45.0
MultiAxisVariable.A4=45.0


PTP {A4 SingleAxisPosition} ; this is ILLEGAL


PTP MultiAxisVariable ; this is LEGAL

You don't distinguish jog and programmed motion. Programmed motion is only possible if axis is NOT at the limit (axis must be inside operating range).

"Impermissible start motion" usually occurs when you have not achieved BCO before running the programmed motion. This happens most often when a LIN motion is used before a PTP has been completed, but I've also seen it with PTP motions when the command position is not fully characterized. One (slightly risky) workaround is to perform a PTP $AXIS_ACT command, or a deliberate move to a fixed location (like $HOME) at the beginning of your program before attempting to use any of these "partial" PTP commands.

Well, normally, you shouldn't even be able to reach (much less exceed) the Soft Limits programatically. Only by manually jogging. And in that case, it's a 'safety' requirement (machine safety, like BCO, rather than operator safety) for someone to manually jog the robot clear of the Soft Limits before programmed motion is allowed.

It is possible. $SOFTx_LIMIT[ ] arrays are not write-protected from the program level.

However, if you hit a limit, I'm not certain that you can recover automagically by opening the limit and then running PTP $AXIS_ACT -- once the fault is active, you may still be forced to manually clear the error in Teach mode. Since the soft limits are used to prevent equipment collisions, KUKA did not want to make it easy for people to cheat their way around them.

A better approach might be to add PID elements to your RSI (not simple, I know) that "push" the axes away from the soft limits as they are approached. Ideally, these "pushbacks" would achieve equilibrium with your commanded motion before tripping the limit errors.

Or an RSI safety cutout -- if any axis comes closer than 1deg to a limit, all the command inputs to the MOVECORR or AXISCORR objects are forced to 0, and an application error raised. Not exactly pretty, but it could avoid running right into the limits.

Avoiding singularity over-speed is harder -- that might require tracking the realtime axis velocities for A4 and A6 into RSI, and applying negative gain to the RSI motion command inputs as those axes approach their velocity maxima.