Simplifying Robotics: Mastering FANUC CRX Plugins and Timeline Editor

FANUC CRX Robots and the Timeline Editor

I contend that programming FANUC robots is easy and can be learned quickly. But what if the idea of writing code is too intimidating or you just don’t have time?

Wouldn’t it be great if you could make the robot do a job without writing a single line of code?

That’s the idea behind FANUC’s new(ish) timeline editor for CRX robots. You basically program the robot by dropping functional blocks onto a timeline. My two-year old could figure it out.

Labeling FANUC Robot IO and Data Directly From Excel

I remember when I first discovered that FANUC robots had the web-based Comment Tool. No longer would I have to endure the pain of trying to mash F1 five times just to get the letter “E”, only to accidentally get “F” due to an extra keypress. I just have to unlock KAREL, head to the robot webpage and start commenting away.

Better, but still not great.

Most of us use Excel spreadsheets to keep track of our robot data, so we still have to manually copy things over from the spreadsheet to the robot.

Isolate Your Wait Statements

Have you ever looked at a TP program and gotten lost following all the LBLs and JMPs? Have you ever gotten lazy handling your WAIT-statement TIMEOUTs because you didn’t want to bother adding the extra stuff to your main routine?

If you’re nodding “yes” right now, you should try isolating your WAIT-statements into their own small programs.

In my eight-plus years of programming robots and troubleshooting other people’s code, I’ve found that a mess of labels and lack of refactoring large programs into smaller routines is the single biggest cause of issues.

Small Programs

FANUC’s TP programming environment is great for creating simple programs quickly. From the comfort of your teach pendant, you can record a few points, turn a few bits on and off and have a fully functional demo within a few minutes. However, as soon as you have to add some real intelligence to your robot, you’ll quickly find the editor to be cumbersome and slow.

I’ve already written about how I write my TP programs by hand, but here’s a quick trick I’ve been using to make my development faster and my programs a little easier to understand: tiny programs. I’m talking really small, like one or two lines.

Programming Multiple Robot Systems Effectively

When dealing with multiple robot systems, I usually find that maintaining consistency from robot-to-robot is usually the most difficult part. Simply getting backups of all your robots can be a pain if you don’t have the right tool for the job. If you’re using Windows (you probably are), just a little knowledge of the command line and the ftp utility will make your life a lot easier.

The Command Prompt

If you’ve never used the Windows command prompt before, read this quick intro from the Princeton CS department.

How to Use BG Logic to Simplify Your TP Programs

TP programs should be readable. If an operator can step through the code and understand it, you might be able to avoid a phone call when the robot inevitably misbehaves. Lately I’ve been simplifying complex conditionals into unique flags to keep my programs short and simple.

Let’s say you have an application where the robot needs to unload one machine and then load another machine. The part out of machine 1 is hot so you want to wait until both machines are ready before unloading the first machine. You might have a line of code that looks like this:

Writing TP Programs by Hand - Pros and Cons

Never Trust an Operator

KAREL syntax highlighting for vim

Writing Maintainable TP Code

Continuing with last week’s theme of best-practices, I’d like to discuss what makes certain programs maintainable and others impossible to work with. Eliminating as much jumping as possible is a good start, but there are a few other rules I always try to follow when working on a project.

1. Keep Programs Short and Focused

FANUC’s Teach Pendant doesn’t have much screen real estate. The default editor can only display 11 lines of code (LOC), and you only get 20 in the Double or Single Wide modes. That means that if you need to troubleshoot a 200 LOC routine on the floor, you can at best only see 10% of the program at any given time.

FANUC TP Syntax Highlighting for Vim

Vim is my favorite text editor. It may take an hour or two to get over the initial learning curve (and probably years to master it), but it’s worth it. The ability to cruise through your code and change it quickly without ever touching a mouse saves a ton of time, and there are plenty of good resources for learning it.

You can grab my syntax highlighting file on GitHub. Pull requests appreciated.

The Perils of Six-Axis Robots

Programming FANUC robots successfully requires you do two things:

1. Write good programs
2. Write good motion

You can’t write good motion without understanding how position data works on the robot. Let’s dive into it a bit and see if we can get a better understanding of how the robot gets from A to B and how we can control exactly how that happens when multiple solutions are present.

Consider a simple arm that rotates around an axis, a single-axis manipulator. This robot can only reach the 360 degree circle around the axis whose radius is the length of the arm itself. There is exactly one joint angle solution for every reachable position.

I, Robot

It’s easy to just move on after merely getting something to work when you’re using an incredibly fast and robust robot. The robot moves the heavy thing from point A to point B and you even have a little cycle time to spare. The customer’s happy; you’re happy; time to celebrate, right?

But what about the robot? Is the robot happy too? Would you be happy performing that task all day? Certainly not, but if you had to do it for a little while, would you do it like you just taught the robot, or would you tweak a couple of things to make it a little easier?

Testing FANUC TP and KAREL Code

UPDATE 2014/02/27:

If you're looking for a how-to guide on FANUC KAREL programming, you're probably better off reading my Introduction to KAREL Programming article.

One of the things I love about the Ruby community is its dedication and support for testing. Having very little formal computer science education, concepts like unit testing and integration testing were completely foreign to me. After first ignoring everyone’s advice to test now and test often, I eventually forced myself to learn out of necessity and now advocate the practice to anyone who will listen. Having confidence in your code is very important, especially when your code is the only thing keeping a $100k robot from crashing through a $500k machine tool. By testing thoroughly, it’s much easier to have confidence in your code and gives you the freedom to perform large refactorings while still maintaining essential functionality.

Intelligent Part-Presence

Good material handling applications typically include many part-presence sensors: proximity switches on fixtures or machine tools, photo eyes or gripper open/closed/overtravel switches on end-of-arm tools, etc. How and when do you use them most effectively?

I check part-presence liberally. If something has gone awry with your automation, you want to realize it as soon as possible to minimize damage. Take a simple pick routine as an example:

1. Make sure the part is present at the fixture
   It doesn’t make much sense to pick a part that isn’t there.
2. Make sure the gripper is open and empty
   The robot will probably crash if the gripper is not open and will almost certainly crash if’s it already gripping a part. If the gripper IO is not functional here, you’ll hopefully detect it before it becomes a bigger problem (e.g. after you’ve picked up a 100lb part).
3. Move to the part
4. Grip the part
5. Make sure the gripper is closed and the part is present within the gripper
   If you have the IO, use it.
6. Retreat from the fixture
7. Make sure the gripper is still closed and the part is still there
   Even if the gripper IO was satisfied at the fixture, it could be a bad grip that lets go as soon as you leave.
8. Make sure the fixture is now empty If a sensor fails, you want to know about it as soon as possible. It’s more important to make this check when loading, but it’s worthwhile checking here too. On the load side, you’ll want to know that a part is incorrectly seated before you bash into that “empty” fixture at 2000mm/s on the next load cycle.

Of the 8 steps in that sequence, 5 involve part part-presence IO. Skipping any one of those checks could be a dangerous oversight.

Clean Code

AP_LD and RT_LD Functions

If you’ve ever worked on a robot with the Constant Path option, you’ve probably seen these funny motion segment modifiers and wondered what they were for.

AP_LD and RT_LD stand for “Approach Linear Distance” and “Retreat Linear Distance.” They guarantee the last (or first on a retreat) Xmm of a given motion segment to be linear. This can be very useful when you need to avoid an obstacle or make sure your motions are not rounding off too soon.

Using Conventions to Improve Your Workflow

As a contract programmer, it’s important for me to be as efficient as possible. Coding faster saves my clients money and allows me to move on to the next project quicker. Over the years I’ve developed quite a few tools and habits that help me do more work faster.

Conventions

I picked up Ruby on Rails back in 2007. One of the things I really like about it is its liberal use of convention over configuration. By defining conventions for things that always come up, you don’t have to waste any time or energy developing solutions for them.

Using FTP for Increased Productivity

One of the easiest ways to save time while working on a FANUC robot is to become familiar with an FTP client. The addition of the USB port on the Teach Pendant helped bring most people out of the dark ages of lugging PCMCIA cards around (although many people still use them), but even USB sticks aren’t the fastest way to get files to and from your robots.

For those unfamiliar with the concept, FTP stands for File Transfer Protocol; it’s basically a method for getting files from one computer to another. One computer (like the robot controller) runs an FTP server and waits for FTP clients (like your laptop) to connect and issue commands. You have commands for getting a list of files, downloading files, uploading files, creating directories, etc. As long as your laptop is on the same network as your robot, you’re good to go.