Writing TP Programs by Hand - Pros and Cons

Filed under: FANUC TP Programming TP+ Workflow

FANUC’s TP programming language and the teach pendant’s built-in editor are great tools. They allow relatively novice programmers to get up and running very quickly. Teach a couple points, throw in a couple labels and IF statements, and you’re off to the races. However, anyone who’s tried to do anything a bit more complex quickly realizes how cumbersome programming on the teach pendant is. Navigating through multiple levels of menus to find the PAYLOAD instruction or creating an extensive mixed-logic conditional is really painful. At this point many programmers switch to programming .LS files by hand.

Here’s the smallest program you can load onto a robot:


/PROG A
/ATTR

However, it might be good practice to start with a template that includes all available sections:


/PROG A
/ATTR
/MN
/POS
/END

The /PROG section simply accepts the name of your program (letters, numbers and underscores only, and it must start with a letter) followed by an optional sub-type (e.g. Macro, Cond, etc.).

The /ATTR section stores the rest of the program header information: things like the creation date, comment, group mask, etc. If you choose not to include any of this, the robot assumes a sensible set of defaults.

I’m not sure what /MN stands for (motion?), but this is where your program goes. You must start each line with a : and end it with a ;. You can optionally include a line number before the colon, but I think including line numbers in your source code is a tragedy.


/PROG A
/ATTR
/MN
 : ! this is a comment ;
2: ! don't do this <-- ;
/POS
/END

At this point there’s no good way of populating the /POS section of your program. I generally upload my program to the robot, teach the point, then use the robot web page to view the program source and copy/paste the position data after positions are taught. Maybe I’ll write something better someday.

Getting the Files to Your Robot

Unfortunately FANUC decided to squeeze an additional $500 out of anyone who needs to do any real programming. The robot will not translate your ASCII *.LS files into binary .TP files unless you purchase the ASCII Upload option.

If you’re lucky enough to have a ROBOGUIDE license, you can side-step the ASCII Upload option by having your virtual robot translate them for you.

Here’s a simple Windows Batch file and FTP script that will upload all .LS files located in ./src to the virtual robot on 127.0.0.2 and then download the .TP files into ./bin:


translate.bat
-------------
ftp -i -s:translate.ftp 127.0.0.2

translate.ftp
-------------
anon
bin
mput src/*.ls
lcd bin
mget *.tp
quit

Note: keep an eye on your virtual robot’s error log or the FTP output to see if any files failed to translate. Also make sure your the currently selected program on your virtual does not to be translated. (Abort all then select another program.)

You might write another batch file to then upload files to your real robot at 192.168.1.101:


deploy.bat
----------
ftp -i -s:deploy.ftp 192.168.1.101

deploy.ftp
----------
anon
bin
mput bin/*.tp
quit

Note: Again, the robot won’t load a file if that file is currently selected on the teach pendant. (Abort all, select another program)

“I Wish I Had Used TP+”

That’s what I said to myself last week while trying to find a rare bug hidden within 15000 lines of TP code. The bug ended up being a simple typo… something like this:


IF (R[1:numreg one]=1 AND R[2:numreg two]=2),JMP LBL[100] ;
IF (R[1:numreg one]=2 AND R[3:numreg two]=3),JMP LBL[200] ;
JMP LBL[999] ;

Can you spot the issue? Here’s how it looks after translating and loading the file onto the controller:


IF (R[1:numreg one]=1 AND R[2:numreg two]=2),JMP LBL[100] ;
IF (R[1:numreg one]=2 AND R[3:numreg three]=3),JMP LBL[200] ;
JMP LBL[999] ;

I meant to use R[2:numreg two] in both conditionals, but I accidentally changed the 2 to a 3 while hastily changing the other expressions. The translator ignores the comment completely, so you have no idea your code doesn’t work until you test it.

This can be particularly catastrophic when using positions and position registers. Tell the robot to move to P[10:position one] when you meant P[1:position one] could be pretty bad. Gotta be careful when programming by hand.

TP+ to the Rescue

Here’s how this program might look if written with TP+:


numreg_one   := R[1]
numreg_two   := R[2]
numreg_three := R[3]

jump_to @one_hundred if numreg_one == 1 && numreg_two == 2
jump_to @two_hundred if numreg_one == 2 && numreg_two == 3
jump_to @end

@one_hundred
  # do something
  jump_to @end

@two_hundred
  # do something else
  @jump_to @end

@end

Of course you can still make typos, but I think it’s a lot harder to mis-type names than numbers. The translator will catch it if you type nmrg_one instead of numreg_one.

Interested?

I introduced TP+ back in January. There’s a demo where you can try it out.

I used TP+ exclusively on my most recent machine tending project, and it was really refreshing. A single environment file holds all variables for numeric registers, position registers, I/O, etc. Namespaces allow me to organize data and I/O into logical groups independent of the robot data numbering.

Let’s say you have to move DI[1] to DI[56] for some reason, and this input is used in 100 programs. Simply update the variable definition in the environment file, re-translate and all the programs are instantly up-to-date.

I’ll release a standalone version of TP+ eventually. Let me know if you’re interested and I might get it done sooner rather than later.


Want posts like this delivered right to your inbox?

If you liked this post, please sign up for my mailing list!