Use Distance Before and set it to minimum value.
The robot model is irrelevant. What is the controller model and the software version?
The main problem with so old system is not its capabilities or spare parts. It may not comply with today's safety regulations.
How do you detect "small collision"?
If with collision guard, the program stops, hence any further code will not execute.
It would be interesting though to test the collision as the skip condition, to see upon the program resume whether the move instruction was skipped before the stop.
This approach only works with fine points. When you use continuous points, the register will change in advance.
But you can set a GO within every movement (that's done in the correct physical position), then use that GO for checking the position.
What do you mean by "set a GO within every movement "? DB?
Unfortunately, the OP's "remember where it's at in a program" is not clear. I would restart based on "where it is in the cage".
This being said, it's unclear why abort the program if it has to be resumed/completed.
$MOR_GRP.$currentline indicates the line number in the program that generated the current or last motion.
So, can you share the solution?
IF instructions with no brackets do not support position registers.
Use IF(...) instruction.
" I don't have the option to use IF with PRs."
What makes you think so? This ability is not an option.
The syntax provided works on R30iA and R30iB.
Are you editing on the robot teach pendant or in PC text editor?
What are your regional settings for decimal separator? Is it . or , ?
The correct syntax with no redundant brackets is:
IF (PR[5,1]>155 AND PR[5,1]<175),JMP LBL
In the move instruction, specify the move time, not speed.
This will automatically apply the necessary linear and rotation speeds.
I am looking for a system variable indicating the joint remaining rotation to the move target.
In any units: degrees, encoder pulses, fraction of the move segment.
I also think this another "improvement" is absolutely useless.
If you want to disable this feature for good, go to the system variable $UI_CONFIG.$ICON_EDIT and set everything to FALSE.
It would be helpful if you post the PR position data and also the rest of the program. Since you have CNT25 these 2 motions will be blended with something else further down your program.
Further down is linear motion in another direction, with no more rotation.
I don't have the positional data handy right now, but would be surprised if it has something with the issue.
First thing I see wrong is that you are using a L movement to move "lineary" to a position that I assume you are storing on "Joint position" coordinates.
Your assumption is wrong, and I don't see any reason for it in my post.
The position is Cartesian.
Second thing is that you are also using another L movement after switching the axis 6 to 90 degrees.
It should be a J movement if you want the robot to respect the speed you are commanding with the 5deg/sec speed....
I am using linear motion, because I need it to be linear. According to the manuals, deg/sec speed specification is fully applicable to linear motions.
Third thing... when you modify PR on the program directly, motion planner calculates a path, then you are modifying the 6th axis position while in movement.
I think motion planner do not look ahead the same way with "PR" as with "P" points, and it may do a fine point instead because of this.
It does not do a fine point.
... as far as I know if you edit PR while on movement the program pointer will stop briefly on every PR assignment before the next move path is calculated....
From my exprience, Yaskawa Motoman does this, but not Fanuc.
If you can, you should use an additional PR just to be sure.
Yes, and I will try asap, but I want to understand the reason of the issue.
Here is a fragment of the program:
!At this point, PR[1,6]=0 ;
!Tool is hanging downwards.
L PR 1000mm/sec CNT25 ;
L PR 5deg/sec CNT25 ;
The idea is to move to clear for rotation, then without stopping switch to rotation.
However, the rotation is done much faster than 5°/sec (times faster).
I understand, that the problem is most probably caused by using the same PR, but still do not undestand why.
5-axis robot, R-30iB Plus,.
These are subprograms, called with parameters in the brackets.
They are most probably written in Karel, not in TP.
It all depends on your abilities on the data source side.
If possible, send always the absolute value, and separately a "negative" flag.
In the robot, convert to negative when necessary, by subtracting from zero.
This being said, what do you need 32-bit values in the robot for?
Signed 16-bit covers more than ±3.2 meters distance with 0.1mm resolution.
"Nobody touched the TP ..."
How can you know that? Users always say this.
Is it a single-time incident or repeated issue?
Do you have anything like PalletTool or PickupTool in the robot? These may use PR[1} for own purposes.
I would avoid such address anyways, as it is the first one you see in the Data screen, hence the most subject to erroneous overwriting.