Robot moves fast, but processes lines slowly

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.

Quote from kluk-kluk

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.

Quote from cmcraeslo

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).

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:

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:

PROGRAM CALC_KL
VAR
i, us1, us2, us_delta : INTEGER
BEGIN
us1 = GET_USEC_TIM
i=0 ;
Add::
i=i+1
IF i<10000 THEN ; GOTO Add; ENDIF ;
us_delta = GET_USEC_SUB(GET_USEC_TIM, us1)
END Calc_KL

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.

Quote from Nation

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.

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.

Quote from SkyeFire

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.

Yep, that's what I did.

Quote from Nation

Yep, that's what I did.

...do your fingers still work?    

I'm guessing you did a script or an Excel sheet that did most of that heavy lifting for you.

Quote from SkyeFire

...do your fingers still work?    

I'm guessing you did a script or an Excel sheet that did most of that heavy lifting for you.

The doubling formula. Just had to copy paste 14 times. 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192, then some change.

Nation I was wondering what is the best way to do a loop without LBL I don't see it on my TP it's a very old tp btw