Hi Everyone!
I'm trying to program an s900 using an r-j3ib controller, and it's motions run smoothly between linear motion points and circle motion points, but when I try to change the speed from a constant to a register variable (to help me fine-tune the process) the robot will slow down and stop for the circle motion, execute the circle motion, then continue on.
Is there a way to have the robot perform the whole motion without stopping using register variable speed?
thanks!
Fanuc robot slows down at points when using register variable for speed?
-
failarmada -
August 15, 2018 at 1:45 AM -
Thread is Resolved
-
-
We do this all the time and have never experienced this. I assume you do not have any fine move at the end of your point?
-
Correct, everything is CNT100. Here's an example of it running continously:
1: UFRAME_NUM=2
2: UTOOOL_NUM=2
3:L P[1] 250mm/sec CNT100
4:C P[2]
: P[3] 250mm/sec CNT100
5:L P[4] 250mm/sec CNT100!!Example of it pausing before circular motion
1: UFRAME_NUM=2
2: UTOOOL_NUM=2
3: R[10]=250
4:L P[1] R[10]mm/sec CNT100
5:C P[2]
: P[3] R[10]mm/sec CNT100
6:L P[4] R[10]mm/sec CNT100 -
Believe or not , it could be processing time
If you think about it, robot get to a point, then access the data base (register) and places the number on the value and executes the action.
When reading 250mm, just reads and execute
Sound like B.S. but that's the way it is
Similar issue, a lot of people use this :
Instead of writing DO[3] = ON , they write a program that contains that line only, but just the fact the the robot has to call a program, delays that output 4ms
-
I was afraid of that, the r-j3ib controllers are pretty ancient and it would make sense that things would slow down for it to check a register value. I was hoping there was some system variable that treated motions differently when speeds were variables.
-
This reminded me of lookahead execution being blocked when using PR on movement instructions, so I checked manual (chapter 9.4 of Operator Manual) to see if it happens even with Registers but seems not.
Anyway I'd give it a try, you just need to 'envelop' your movement instructions between LOCK PREG and UNLOCK PREG instructions. -
That would make sense, but it looks like it just works for position registers (I just tried it and it still had the same abrupt motions) Although, I'm glad that I know about LOCK PREG now
-
I was having a problem once with RPM and speeds from register. I had to set $RGSPD_PREXE=1 to enable speed register pre-execution. Maybe this will help ...
-
YES!!!!!!
THANK YOU DHA! That was exactly the problem...I knew there was some kind of hidden system variable fix. It was a write protected variable so I had to do a controlled start to change it, but now it's running great! Although I'm not sure why it would default to FALSE...
Thanks everyone! -
Although I'm not sure why it would default to FALSE...Because it can lead to "strange" behaviour.
The controller will now read ahead (a few lines) in your program and essentially make a copy of whatever value you have in your register when it encounters the motion instructions.
This copy is the value that will be used.
If you have a program where the register values are constantly updated, making copies like that can lead to lost updates, where an old value is used instead of the new one.
Setting $RGSPD_PREXE to true must be a decision made by the robot programmer as it has consequences for all programs and ultimately the behavior of the robot.
-
Good to know, I'll keep an eye out for registers not appearing to update. Thanks