FANUC Robot Programming

I'd been programming since I was a little kid, so the case-packing program showed me some pain immediately. Do I really need to teach a unique point for each of these drops? Does TP have arrays or something? There must be a better way.

I asked around, and sure enough, someone showed me the Position Register screen. Not exactly what I was looking for, but it would definitely help. With Position Registers I could teach one point and generate subsequent positions relative to it. I could also use Frame Offsets and Tool Offsets to get a nice motion profile without repeating myself.

My point is this: you can't fully understand what programming a FANUC robot involves until you do it. You need someone to show you the basics and then let you loose on a project. Use your brain, try your best, experience some pain — and then see if there's a better way.

That's what I tried to do with my book, Robot Whispering. We start with the basics, then build up a simple application from scratch, sometimes doing things the hard way before refactoring into something better. I think that's the best way to really learn how and why to do things a certain way.

That's it. There are finer details — there's probably a lot of logic inside "move safely to the target station" — but that's the recipe for most tasks.

For efficient motion, I always think about getting from A to B with as few points as possible, as fast as possible, using CNT100 as much as possible. Joint moves are ideal if you can swing it. Your robot can easily get wrapped up with lots of linear moves and never using a joint move to force the correct joint configuration.

KAREL is used for the more complex tasks TP cannot do: reading and writing files (see also writing a logging utility), socket messaging, position transformations, monitoring, custom user interfaces with the FANUC form manager, complex multi-tasking, and so on.

For an experienced programmer, KAREL is nice because it gives you typed variables, custom data structures, routines with variables passed by reference, return values. It's easy to test — particularly because we're generally not doing any motion with KAREL. You'll have to shell out to a TP program if you want to move the robot.

Alarms (see how to diagnose FANUC alarm and error codes), File and System are probably the only other top-level items I use day to day.

It takes a little time to get comfortable with where everything is, but you generally get there via the shortcut or MENU, then use F1–F5 (and maybe Prev/Next) to operate the screen.

LBL[1] ;
CALL GET_TASK_ID_FROM_PLC ;
SELECT R[1:TaskID]=1,CALL TASK_001 ;
       =2,CALL TASK_002 ;
       =3,CALL TASK_003 ;
       ELSE,JMP LBL[501] ;
JMP LBL[1] ;

Where GET_TASK_ID_FROM_PLC might be something like:

LBL[1] ;
WAIT (GI[1:TaskID]<>0) TIMEOUT,LBL[501] ;
R[1:TaskID]=GI[1:TaskID] ;
GO[1:TaskID]=R[1:TaskID] ;
WAIT (GI[1:TaskID]=0) TIMEOUT,LBL[502] ;
END ;
 ;
LBL[501] ;
! timeout waiting for task ;
! TODO: alarm? ;
JMP LBL[1] ;
 ;
LBL[502] ;
! timeout waiting for task ack ;
! TODO: alarm? ;
JMP LBL[1] ;

Or if you're just using DIs:

LBL[1] ;
R[1:TaskID]=0 ;
IF (DI[1:Run Task001]),R[1:TaskID]=(1) ;
IF R[1:TaskID]<>0,JMP LBL[999] ;
 ;
IF (DI[2:Run Task002]),R[1:TaskID]=(2) ;
IF R[1:TaskID]<>0,JMP LBL[999] ;
 ;
IF (DI[3:Run Task003]),R[1:TaskID]=(3) ;
IF R[1:TaskID]<>0,JMP LBL[999] ;
 ;
! no task given ;
! maybe add a short wait ;
WAIT 0.01(sec) ;
JMP LBL[1] ;
 ;
LBL[999] ;
END ;

You basically want to write clean code that's easy to maintain.

For anyone used to declaring named local variables or passing values to functions, this is a bit of a rude awakening. I hated it so much that I wrote my own programming language.

If the NUT/FUT or turn-count stuff is new, read The Perils of Six Axis Robots.

For DCS, you'll have to do your own safety analysis, but a good rule of thumb for the gap between DCS and your fence:

It's best to verify there's a big enough gap early in the project, so the engineers can adjust the layout or guarding if necessary.

Once the big motion decisions and DCS are out of the way, get a head start on homing. I like to use the exact same retreat routines for my main high-speed production routines as I do for homing — that way I know these routines have a lot of runtime on them and don't only run once in a blue moon. I also don't have to write essentially the same logic twice.

To test homing, I run a routine and stop the robot at various points throughout the motion, then abort and run the homing routine. The robot should home just fine. If it faults or does something weird, fix the homing routine. When homing from a station, I write code assuming the robot is the furthest it can get into a station and write retreat code from there:

CALL PROGRAM_TO_VERIFY_ROBOT_IS_AT_STATION ;
 ;
UFRAME_NUM=1 ;
UTOOL_NUM=1 ;
PR[x:LPOS]=LPOS ;
 ;
! assume robot is at pick position at this point ;
! and write a check to falsify that assumption ;
IF (PR[x,3:LPOS]>a),JMP LBL[1] ;
! robot is probably at pick — move to first retreat ;
PR[x,3:LPOS]=a ;
L PR[x] 500mm/sec CNTx ;
 ;
LBL[1] ;
! ok we are at least at Z=a ;
IF (PR[x,1:LPOS]<b),JMP LBL[2] ;
! need to move back to b ;
PR[x,1:LPOS]=b ;
L PR[x] 500mm/sec CNTx ;
 ;
LBL[2] ;
! ok we're at least Z=a and X=b... ;
J PR[y:perch] 100% CNT100 ;

Testing KAREL programs

As I mentioned, testing KAREL is easy to do. It's also pretty important, because you're probably doing some complex stuff.

It's not necessary, but I wrote KUnit back in 2014 to help with simple assertions while testing KAREL. I run a cygwin console environment and use curl to hit KUnit and run all my tests right from the console — make test.

If I have a KAREL library called lib, I'll have a program called test_lib.kl with a routine per routine I need to test:

PROGRAM test_lib
...
ROUTINE test_add
VAR
    result : INTEGER
BEGIN
    kunit_test('1+1=2', kunit_eq_int(2, add(1,1)))
    kunit_test('2+2=4', kunit_eq_int(4, add(2,2)))
    kunit_test('4+1=5', kunit_eq_int(5, add(4,1)))
END test_add

BEGIN
    kunit_init
    test_add
    kunit_done
END test_lib
      

HOST ?= 127.0.0.2

test:
    curl -m 5 http://$(HOST)/karel/kunit?filenames=test_lib
    curl -m 5 http://$(HOST)/karel/kunit?filenames=test_lib2
      

KUnit supports passing multiple filenames at once, but it runs those in parallel — which may not work if your code isn't threadsafe. I usually just test each file with its own HTTP call.

THE BOOK

Robot Whispering

The unofficial guide to programming FANUC robots — start to finish.

Get the book →