When I first learned to program FANUC robots, I was bothered by the TP programming language. At the time I was using Ruby primarily, which, according to the official website, “has an elegant syntax that is natural to read and easy to write.”
I was annoyed that I had to manage my own memory locations for numbers, positions, I/O, etc.
Wouldn’t it be nice if I could program FANUC robots with Ruby? …or at least something Ruby-esque?
Enter TP+ back in 2014. At last… the holy grail! Named variables for numregs, posregs, I/O, etc., namespaces, constants, labels, syntax that’s easy to read and write… what else could you need?
Well the truth is I only really used TP+ on one production project, and although others continue to use and develop the language, I wasn’t happy with the workflow.
The TP+ source code was too far-removed from the eventually-compiled TP source that ran on the robot. Fixing bugs was a bit of a pain, and it was pretty difficult to find differences between two sets of source files that are in two very different languages.
It only took seven more years of programming TP the old way before I realized I could have the best of both worlds: standard TP programs with the power of named variables and constants.
Luckily I had already written a tool in 2019 that did most of the hard work…
Fexcel, the tool I wrote to simply help with labeling robot data, can now supercharge your LS files.
Basically you use an Excel spreadsheet to define all of the robot stuff you care about: numeric registers, position registers, I/O, etc., and then you can use those definitions directly in your code without worrying about where they are located.
Here’s a quick example:
UFRAME_NUM=${UF_WORLD} ;
UTOOL_NUM=${UT_FACEPLATE} ;
;
PR{lpos}=LPOS ;
IF (PR[&PR{lpos},${Z}]>${MIN_Z}),JMP LBL[1] ;
;
PR[&PR{lpos},${Z}]=${MIN_Z} ;
L PR{lpos} ${SAFE_SPEED}mm/sec CNT0 ;
;
LBL[1] ;
J PR{home} ${HOME_SPEED}% CNT0 ;
Depending on your spreadsheet’s definitions, this may translate to:
UFRAME_NUM=0 ;
UTOOL_NUM=0 ;
;
PR[2:lpos]=LPOS ;
IF (PR[2,3:LPOS]>500),JMP LBL[1] ;
;
PR[2,3:lpos]=500 ;
L PR[2:lpos] 100mm/sec CNT0 ;
;
LBL[1] ;
J PR[1:home] 20% CNT0 ;
The source code is the same line-for-line. The only difference is the variable and constant definitions have been replaced with their values.
Most of the time I start filling out my robot spreadsheet before I write a single line of code. With fexcel you don’t have to. If I tried to compile the above example against a blank spreadsheet, the tool would output:
example.ls:1:11: ${WORLD} is undefined
You could write your code first and then figure out where you want your data to go later.
No More Typos
Just checking typos has been huge for my development workflow. I can’t tell you how many times I’ve fat-fingered a register index and regretted it. (e.g. R[12:numreg thirteen] OOPS!)
Easy to Move Stuff Around
It also used to be a huge pain to move my data around. I’d have to use grep or something to find every instance say R[1] was used and then update it by hand. Now that the data indices are nowhere to be found in the code, you can just update your spreadsheet and recompile.
Don’t use Registers for Things the Customer Shouldn’t Change
I’ve been guilty of this in the past… using a register for a speed or CNT-value to tweak things during development. This is fine, but once a good value has been found, that register should really be swapped out for a constant. Fexcel doesn’t find rogue variables for you, but it does make it easy to try new values for constants (and the value is saved to your spreadsheet for reference later in case someone changes it.)
Try it Out
If you’d like to give fexcel a try, head over to the releases page and download the latest release. (NOTE: fexcel is a command-line utility. There is no GUI, so you’ll have to use it from a command prompt and may need to place the executable on your system $PATH before using it.)
There’s a fairly complete material handling example in the source repository.