Fanuc robot slows down at points when using register variable for speed?

    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!

    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

    Retired but still helping

    Edited once, last by Fabian Munoz ().

    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 :icon_smile:

    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!

    Quote from failarmada


    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.

Advertising from our partners