Robot moves fast, but processes lines slowly

  • Hello all.


    We're trying to run our first robot (we built it for our own use) and i'm having difficulties running it at speed I want. It looks like the moves are good and smooth and I can control how fast they run via data registers (run speed override etc), but the logic processing seems to be slow. There are few calls within the main program and it looks like it waits between the calls. There's nothing fancy in these calls, but it stops and waits for no reason between them.


    Here's the video of robot in action. You can clearly see that it "stops" between some of the moves. It's best shown at around 15 seconds when robot loads the part to a palette (coming from cnc), then moves to another palette and loads it from that palette. You can see that it "stops" for a brief moment, doing "nothing".


    Imgur
    imgur.com


    What could be causing this?

  • AD
  • Lemster68

    Approved the thread.
  • Edit: I do switch user frames between rows - could this be the reason this is happening? If yes, how can I avoid the delay?

  • It is because the speed is in a variabele.

    The robot will stop every time to see if the variabele has been changed and resume when made the speed according to the actual value.

    As far as I know there is no way to lock the variabeles, so when you want the speed in a variabele you will have to live with this.

    If you want a smooth movement with no stops, change the speed in the instruction to a constant. (a fixed number)

    In that way the robot knows what is coming.

  • It is because the speed is in a variabele.

    The robot will stop every time to see if the variabele has been changed and resume when made the speed according to the actual value.

    As far as I know there is no way to lock the variabeles, so when you want the speed in a variabele you will have to live with this.

    If you want a smooth movement with no stops, change the speed in the instruction to a constant. (a fixed number)

    In that way the robot knows what is coming.

    I don't think it's that problem, I've done it on several occasions and at Fanuc I've never had that problem writing the speed from a register or group input.


    To me it seems more like a WAIT instruction, or some condition that is not being met.

  • I do switch user frames between rows - could this be the reason this is happening?

    Maybe. When possible, you should avoid move instructions and computation on frames or PR instructions mixed together. It increases the CPU load and thus may reduce the robot cycletime (infos from Fanuc guys).

  • I was able to find the main problem for my delays. It's some calculation I do between the path, to update palette registers and that for loop (4 x 32 items) took 1.5s to calculate. I optimized it to 0.5s and it's much better. I come from a different (microseconds) environment and the processing speed in this robot is very disappointing :)


    I also replace the FINE moves to joint and/or CNT which improved the speed a lot.


    Unfortunately replacing all the move lines with fixed speed is not an option at the moment. We have different loads and payloads and set these accordingly. That being said, even if I did just replace it with the fixed speed, it'd not be able to work "ahead" as most of the next moves are calculated as the robot moves. There are not many fixed paths.


    It's fully automated placement to 32 palettes, distributed evenly over the rows.

    Operators will only have 4 buttons: load, unload finished, unload unfinished and auto (cnc operation).


    Videos:

    Imgur
    imgur.com

    Imgur
    imgur.com

  • Yes all Fanuc robots are very slow (compared to other processors) to process register instructions. You can try to optimize by doing that ahead of time or in Background (BG Logic), or offload that processing to a PLC.


    A for loop like that would be milliseconds on a good PLC or PC.

  • This got me interested in how fast it takes for tp vs karel to run calculations, so I ran a test.


    Here are the test programs:


    TP:

    Code
    1: TIMER[1]=STOP ;
    2: TIMER[1]=RESET ;
    3: TIMER[1]=START ;
    4: R[100]=0 ;
    5: LBL[1] ;
    6: R[100]=R[100]+1 ;
    7: IF R[100]<10000,JMP LBL[1] ;
    8: TIMER[1]=STOP ;


    Karel:


    Results:

    Time for Karel to count to 10000: 5174us, or 0.005147 seconds.

    Time for TP to count to 10000: 159.95 seconds! That is 32 THOUSAND times slower!

    Edit: if you unroll the loop, it completes instantly.


    I knew TP was slow for calculations, but Jesus. This is really bad. I also did this in roboguide, so I would expect a real robot to be even slower.

    Check out the Fanuc position converter I wrote here!

  • Time for Karel to count to 10000: 5174us, or 0.005147 seconds.

    Time for TP to count to 10000: 159.95 seconds! That is 32 THOUSAND times slower!


    Edit: if you unroll the loop, it completes instantly.

    :icon_eek: Yowza.


    By "unroll the loop", you mean write 10000 single-line Reg=Reg+1 statements? That would suggest the bottleneck is the JMP, or possibly the IF.


    Now I have to wonder how slow Trig functions are. In classic mainframe computing (1960s), programmers would often jump through all sorts of hoops to avoid doing COS, SIN, or TAN to the greatest extent possible.


    I have to wonder what makes TP so slow -- if KAREL can run that fast, the processor and OS obviously have enough raw power.

  • I think the TP code executes on a fixed 8ms scan cycle. My theory is that certain instructions cause it to end processing until the next scan. If you take 159.95 second divided by 10000 counts and 8ms that equates roughly to 2 scans per loop.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now