Workflow

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. Writing TP Programs by Hand - Pros and Cons

    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.

  7. Never Trust an Operator

    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.

  9. 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.

  10. 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.

  11. The Perils of Six-Axis Robots

    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.

  12. 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?

  13. 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.

  14. 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: Make sure the part is present at the fixture

  15. Clean Code

    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.

  16. 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.

  17. 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.

  18. 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.