Posts

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

  2. Asynchronous Part-Presence Checking (When the Robots are Too Fast)

    I’ve spent a lot of time working on high-speed line tracking (iRPickTool) applications. When I first started working on them back in 2008, throughputs around 100 cycles per minute were really pushing the envelope (but this was when FANUC’s flagship high-speed picking robot was the M-430iA). Since then FANUC has introduced a number of Delta robots: the M-1iA in 2009, the M-3iA in 2010, the M-2iA in 2013(?) and the DR-3iB in 2019.

  3. Programming FANUC Robots with Variables and Constants

    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?

  4. How to Diagnose FANUC Alarm Codes and Error Codes

    It’s inevitable. You’re setting up your robot, programming it or running production, and you come across an alarm code that you don’t recognize. What do you do? Call tech support? Google? Read the manuals? Based on some of the questions I’ve seen, I think a lot of people are unaware of the troubleshooting resources available at their fingertips. Your robot probably has a ton of help files and documentation available right on the teach pendant.

  5. Four Ways to Control FANUC Robots' Speed Override

    Imagine this: you have a robot that easily keeps up with its task (trust me, these applications do exist!). Like a considerate parent, you allow the robot to run at 70% which still gives it a little time to rest between cycles. But every time you walk by the cell, the teach pendant shows a glaring 100% override. The robot works its ass off for a few seconds and then sits there motionless, waiting for the next part to come down the line.

  6. Refactoring Skip Conditions

    In my last article we talked about FANUC’s Skip Conditions: how they work, where you might use them and why they can be confusing. We also discussed the SkipJump option which may have better semantics. Today I want to use the Skip Condition syntax as an opportunity for refactoring. We’ll work with TP parameters and their corresponding argument registers (AR[]), side-step some argument register limitations, discuss return values and eventually create a pretty powerful two-stage search algorithm that has high accuracy without sacrificing cycle time.

  7. How to Search with a FANUC Robot Using Skip Conditions

    Have you ever needed your FANUC robot to search for something and stop when it “sees” it with some sort of sensor? There are probably 100 ways you could pull this off (macros, background logic, manipulating UOP signals, etc.), but if you’ve been programming FANUC robots for a while, your first thought is probably “SKIP CONDITIONS!” followed almost immediately by “How exactly do those work again? I remember them being kinda weird.

  8. How to RUN FANUC Programs Concurrently with the RUN statement

    Every once in a while I get asked about FANUC’s multitasking capabilities: “Can I do multitasking with a FANUC robot?” “How do I run a background task with FANUC?” “How do I run an aux axis independently while the robot is doing other stuff?” The short answer is yes, but there are a number of options. Which one’s appropriate depends on your use-case. Option Environment Background Logic Setup (can run TP or KAREL programs) The RUN statement TP (can run TP or KAREL programs) AUTOEXEC programs System Config (can run TP or KAREL programs) Condition Monitors TP Condition Handlers KAREL PMC (Programmable Machine Control)* Ladder logic *NOTE: PMC requires a robot software option and the FANUC Ladder PC software.

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

  10. TP Programming With Interfaces

    I worked on a palletizing project recently that required serialization. In effect, the product must be tracked through every stop of the process: Product picked Inspection passed Inspection failed Product moving to pallet Product placed on pallet Product dropped Product rejected The robot simply sends a Digital Output signal to the PLC when any of these events takes place, and the PLC is responsible for sending signals on to the customer’s serialization service.

  11. How to Write a FANUC KAREL Logging Utility

    I received a question via email the other day where someone wanted to know how to log timestamped position data to a file. As luck would have it, I’d been meaning to write a post about something like this for quite a while now. This application ends up being a great example that covers a broad range of KAREL programming fundamentals: KAREL variables, constants and data types Custom ROUTINEs String manipulation Bitwise operations TPE parameters Error-checking and the status convention File operations File pipes (the PIP: device) Data formatting Let’s get started by considering our desired TPE interface.

  12. Teaching Points Backwards

    I was with a customer earlier this week who needed a little help with one of their robots. It was a simple pick and place application, but for one reason or another, one of its placements had drifted and now the robot was fumbling that drop at overrides over 70%. Pretty simple fix, right? Put the robot in teach, pick up a part and then step it through the place routine.

  13. Coming Soon

    I wasn’t great about blogging in 2016, but I did ship a few things: A new site design that was long overdue. Several blog posts, most notably a guide to starting FANUC robots in AUTO, a guide on using pipes in KAREL and an open source hash table implementation for KAREL. Several updates to KUnit, a unit testing framework for KAREL. With a proper development environment, you can test your KAREL libraries from the comfort of your command console.

  14. Embrace the END Statement

    What do you think this line of code does? JMP LBL[9999] ; If you’ve been programming FANUC robots for a while, you probably guessed that this statement jumps to the end of the program. It comes in many variants: JMP LBL[999], JMP LBL[10000], etc., but the intent is almost always the same: end this routine. The problem is that there’s no guarantee that LBL[9999] or LBL[10000] or whatever actually ends the routine.

  15. Using KAREL Pipe Files

    I’m currently working on a project where two separate tasks need to pass data to eachother. How do we do that in KAREL? Enter the pipe PIP: device. The concept of a pipe has been around since the early 1970s, originating as a crucial part of the Unix operating system. Pipes simply provide a mechanism for data to travel from one process to another. While the KAREL manual does a pretty good job of describing how pipes work and how to use them, I ran into a couple of issues while implementing the provided example.

  16. Starting FANUC Robots in AUTO

    You’ve finished programming your robot, tested it in T1, and now you want to run it faster. If you’re like me, you sometimes forget the details on Remote vs. Local, UOP signals and the different startup types available (RSR, PNS, Style, Other). For your (and my own) reference, here’s a quick no-BS guide on how to get things running. NOTE: If you like this post and are interested in the programming side of things, be sure to check out my book on programming FANUC robots.

  17. Hash Table Implementation for FANUC KAREL

    I was working on a KAREL project the other day where I really wanted to use an associative array to store some key => value pairs. While a STRUCT would be appropriate if my keys were known ahead of time, there’s no data type for mapping unknown keys to values… …so I built a hash table implementation that you can use in your own KAREL programs. The source is available here: https://github.

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

  19. Smart Payloads

    My last project was a machine load/unload application where the robot had two basically identical grippers. Either gripper could be used to load or unload any station. Here’s how I handled the payload switching and grip/ungrip logic in the load/unload programs.

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

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

  22. TP+ is Open Source

    This post is about 6 weeks overdue, but the full TP+ source code is now available on GitHub. I’ve already accepted some improvements from Group Six Technologies Inc, and I’m happy to accept more. TP+ should still likely be considered beta software, but feel free to play around with it in the comfort of your own console (instead of the demo site). Please give it a try and let me know what you think!

  23. Review of 2014

    2014 was a great year for the blog despite my apparent inability to write past late August. As a light reintroduction to the sport of blogging, I figured it would be useful to highlight some of the most popular, overlooked and (I think) cool posts from last year in addition to some stats I find interesting. Most Popular Posts of 2014 Though technically posted in 2013, my Introduction to KAREL Programming was by far the most popular post on the blog.

  24. Line Tracking - How Does it Work?

    After a little digging into my records, I found that nearly 60% of the projects I’ve been involved with over the last three years have used vision and/or line tracking. It seems like integrators and end-users tend to need more help when using these options. If they’re lucky, they may have been trained by an expert somewhere, but they’re often stuck with just a manual (if they’re that lucky) to try and fix some pretty obscure bugs.

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

  26. Polish

    Programming FANUC robots is easy. Giving the robots enough intelligence to run safely and reliably in just about any failure scenario is the hard part. This is where many integrators get into trouble. They don’t plan enough programming time on the front-end so that they are forced to add polish on the production floor. If your FAT is just a day or two away and your code isn’t sprinkled with all sorts of (hopefully rarely used but thoroughly tested) error recovery routines, you’re in trouble.

  27. When to use Tool Offsets vs. Frame Offsets

    I used to be a frame offset (PR Offset) guy almost 100% of the time. Assuming you are using accurate UFRAMEs and UTOOLs, this should get you pretty far in material handling. However, once things stop being perfect and your tolerances start getting really tight, you might be better off using tool offsets in your pick and place situations. UTOOL_NUM=1 ; ; ! pick product from fixture 1 ; UFRAME_NUM=1 ; L P[1:pick] 1000mm/s CNT100 Offset,PR[1:pick approach] ; L P[1:pick] 250mm/s CNT0 ; CALL GRIP ; L P[1:pick] 500mm/s CNT100 Offset,PR[2:pick retreat] ; ; !

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

  29. Backup Tool for FANUC Robots

    The process of sticking PCMCIA memory cards (or now USB sticks) into each one of your controllers, going to the FILE menu, creating directories, Backup > All of the above, etc. is a huge pain. I felt this pain very sharply when working on an 18-robot line years ago. BackupTool allows you to concurrently backup all the robots on your project to your PC with a single command. Download BackupTool v0.

  30. Robot Work Envelope Considerations

    Put your robot in a good spot or suffer the consequences. It may seem obvious, but the best programming in the world may not be able to save a system where the robot has to struggle to get from point A to point B. Palletizing One of the first problems I had to solve as the newly appointed M-410iB product manager back in 2008 was where both an end-user and an integrator were blaming FANUC for overheat and throughput problems.

  31. Visual Line Tracking is Hard

    I spent last week helping an end-user with their two-robot visual line tracking system. As far as systems like these go, this one’s pretty simple: just two robots, one backlit conveyor, one camera and basically one product. The entire codebase comes in well under a thousand lines. We had issues that were hard to solve despite the simplicity. What follows is my process while debugging several common visual tracking errors.

  32. Simulating TP Programs in the Browser with tp.js

    Last week I wrote about Testing TP Programs with Ruby, but you had to trust that I wasn’t just making things up. Over the past few days I’ve ported most of my work into a JavaScript library so you can actually see TP programs running directly in your web browser. Let’s cut to the chase and do an example. I’ve written a simple TP program below that performs a few basic functions like numeric register assignment, conditional evaluation, jumping to a label and linear motion.

  33. Testing FANUC TP Programs with Ruby

    I’ve written about testing before, but I still can’t get over the fact that the state of the art method for testing multi-million dollar industrial robot cells is trial and error. That’s why I’ve started working on an environment for reliably testing FANUC TP code. I’ve basically written a Ruby gem to correctly parse, interpret and execute TP programs within a simulated runtime. With this environment I can use any of Ruby’s great testing tools to make sure the robot does what it’s supposed to do.

  34. Building a Robot from Scratch

    Robotics as an engineering science is about as multi-disciplinary as it gets. There’s electronics, motion control, hardware, dynamics, kinematics, user interface, and a whole slew of other very complicated components that eventually create a useful robot. As a contract programmer, I usually only touch the high-level software side. However, with a few weeks to myself recently, I’ve been taking steps to more fully understand the rest of the picture.

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

  37. Introducing KUnit: a simple unit testing framework for FANUC's KAREL programming language

    I’m happy to share a real open source project that I’ve been working on: KUnit. The source code is available on GitHub: https://github.com/onerobotics/KUnit. Coming from a Ruby background where automated unit testing is common-practice, it’s frustrating to come work on a robot where tools for automated testing don’t exist. No matter how careful I am when making changes to my code, I always feel a little bit exposed without a comprehensive set of unit tests making sure I didn’t break something.

  38. Keep it Running

    Any automated system is crippled when it requires human intervention. One of our goals then as programmers should be to eliminate as much human intervention as possible. I’ve found that simply changing many check conditions to short WAIT statements results in fewer alarms and therefore less operator intervention and more productivity. Take for example a simple macro to ensure your gripper has correctly gripped your part: ! ENSURE_GRIP.LS ; ! ============= ; LBL[1] ; IF (RI[1:Grip overtravel]=OFF AND RI[2:Grip open]=OFF),JMP LBL[999] ; ; !

  39. Intelligent Traversing

    I’ve been working on several machine-tending applications lately. These projects tend to get complicated quickly as the robot decides where to go next based on the state of the peripheral equipment. The decision-making logic is hard enough, but getting the robot to and from each station safely can be tricky. This is how I handle it. I start off by defining a list of stations: Home Inbound parts Regrip station Machine 1 Machine 2 Reject station Inspection station Outbound parts I then define a register for saving the robot’s current location.

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

  41. TP Syntax Highlighting with Pygments

    You have noticed that the snippets of TP code in my previous posts now have pretty colors. I created a custom fork of GitHub’s pygments.rb that adds a lexer for FANUC TP. I’m going to maintain and improve this custom fork for a while until the lexer is a bit more complete, then I will see about submitting the patch to the official Pygments project. Here’s an example: /PROG EXAMPLE /ATTR OWNER = ASCBIN; COMMENT = "Example TP file"; PROG_SIZE = 2651; CREATE = DATE 14-01-02 TIME 10:12:44; MODIFIED = DATE 14-01-02 TIME 10:12:44; FILE_NAME = ; VERSION = 0; LINE_COUNT = 21; MEMORY_SIZE = 3195; PROTECT = READ_WRITE; TCD: STACK_SIZE = 0, TASK_PRIORITY = 50, TIME_SLICE = 0, BUSY_LAMP_OFF = 0, ABORT_REQUEST = 0, PAUSE_REQUEST = 0; DEFAULT_GROUP = 1,,,,; CONTROL_CODE = 00000000 00000000; /APPL LINE_TRACK; LINE_TRACK_SCHEDULE_NUMBER : 1; LINE_TRACK_BOUNDARY_NUMBER : 1; CONTINUE_TRACK_AT_PROG_END : TRUE; /MN 1: !

  42. Don't Jump Around

    I hate to disagree with the wise words of House of Pain, but excessive jumping around is the most common issue I see when reviewing others’ TP code. Labels and jump-statements come natural in a language that doesn’t support actual code-blocks for simple if-statements. Within just a few minutes of programming, a beginner sees an IF (…),JMP LBL[X] and decides that this is how FANUC programming is done. Randall Munroe from xkcd sums up the potential for catastrophe when using GOTO statements (TP’s JMP) in this comic:

  43. Your First Visual Tracking Application Part Two

    In part one of this series, we covered gripper design and testing, vision considerations, robot selection, cell layout and choosing the correct number of robots for visual tracking applications. This post will cover some other considerations: conveyor flow, hardware requirements, setup and configuration, and finally, programming. Here’s the full list with links to each section: Gripper Vision Robot Selection Layout Number of Robots Relative Conveyor Flow Direction Hardware Setup Programming Relative Conveyor Flow Direction If you consider a simple system with two conveyors: one for parts coming in, and one for parts going out, which direction(s) do they go?

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

  45. Your First Visual Tracking Application - Part One

    Visual tracking is intimidating, much more intimidating than most other material handling applications. With all the additional hardware required (cameras, encoders, multiplexers) and steps to get things moving (camera calibration, tracking frame calibration, vision process creation, reference setting, accuracy tuning), it’s easy to get overwhelmed. And you haven’t even made any of your other extremely important decisions yet: what robot(s) should I use? What is the best layout for this application?

  46. Intro to FANUC Background Logic

    FANUC’s Background Logic feature is basically the ladder-logic you know and love in TP Program form. These programs only consist of Mixed Logic statements (e.g. F[1]=(DI[1] AND DI[2])), and the programs are constantly scanned in the background while your robot is online, ignoring all E-Stops, alarms, etc. Depending on the complexity of your system, you may be able to skip the PLC and simply use BG Logic to control everything.

  47. Introducing TP+

    TP+ is a slightly higher-level language that translates into valid FANUC TP code. Its goal is to make programming FANUC robots easier. TP+ includes a number of features from newer programming languages that TP does not support. Features Variables for registers, I/O, etc. Automatic label numbering IF-ELSE blocks Improved readability Less stringent syntax Syntax sugar Demo You can try out TP+ here: TP+ Demo Example code: Paste this code into the demo and see how it’s translated into TP.

  48. Introduction to KAREL Programming

    You can do just about anything with FANUC’s TP programming language, but there are some things it just can’t do. Enter KAREL. KAREL is a lower-level language very similar to Pascal. It features strongly typed variables, constants, custom types, procedures, functions, and gives you access to all sorts of useful built-ins for things you may not be able to do with TP. (By the way, if you’re interesting in TP programming, please check out the book I wrote on programming FANUC robots.

  49. UFRAMEs and UTOOLs

    One of the great things about FANUC’s TP programming language is that just about anyone, with very little training, can pick up a teach pendant, write a few lines of code and get their robot moving. The language is very high-level and fairly readable so even someone without a programming background can generally understand what each line of code does. But what if something goes wrong? The problem with making a tool that’s so beginner-friendly (but still very powerful) is that beginners often struggle on fairly basic problems because they don’t understand the lower-level mechanics and software.

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

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

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

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

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

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

  56. To ACC or not to ACC

    That is the question. And the answer is “probably not.” Once a programmer learns that the ACC instruction exists (and figures out how to make it go over 100) this is often the first place they go to make the robot faster. It’s such an easy change to make with immediate results, but there are serious consequences. I’d argue that going over ACC100 should only be done as a last resort.

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

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