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.
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.
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.
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.
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.
Programming robots can seem easy. You can get a robot moving around for a quick video demo in minutes. Even a tradeshow cell that needs to run perfectly for a day at a time isn’t too bad because the environment is controlled. Once you give up that control and hit the factory floor, however, the game changes. Here we have to validate everything, double-check it all and keep the robot safe when it gets misinformation.
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.
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.
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.
Split the arm into two segments with an additional axis between them. You can still reach the original circle, but you’ve also given your manipulator the ability to address the area within.
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?
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.
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:
Make sure the part is present at the fixture
We’ve all been there: asked to work on a project where some or all of the programming has already been done. You pick up the teach pendant to find a program called MAIN which contains 1000 LOC with a mess of labels, old sections of code that are jumped out and may even be controlling other parts of the machine at the same time. If you’re lucky, there might be some comments or thoughtfully-labeled sections, but it’s still going to be a nightmare to work on.
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.
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.
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.