Our Sites

Offline programming of welding robots

Oh, the places you’ll go and the productivity you’ll achieve!

Just because you want to do some robot programming doesn’t mean you need a robot. Offline programming has come of age, and using this now mature and trustworthy technology—in the words of the famous Dr. Seuss—“Oh, The Places You’ll Go!”

Offline programming provides much more than simply the ability to program a robot from your desk. A program created on your PC can be downloaded into the robot, and, depending on how carefully you’ve calibrated the physical system with the software simulation, your program can be quite close. Perhaps just a minor touchup is necessary, or in some cases, no touchup at all is needed.

What Is Offline Programming?

Let’s begin by defining the lingo. When I use the word model, I am referring to the software representation on a PC of an actual robot system. The robot and peripheral equipment sitting on the production floor are simulated and emulated on a computer, and this emulated representation is the model.

The term system represents the actual hardware sitting on the production floor, which includes the robot and any other related equipment that will need to be dealt with. The system also includes the fixtures for holding the components being welded and the weldment itself.

The word simulation represents any simulated function, movement, or process displayed on the computer screen that is meant to mimic the same function, movement, or process of the actual shop floor equipment (the system).

In general terms, offline programming software provides you with a software model of the actual robot cell on the production floor. The software comes with a working, moving 3D model of the equipment, which has the same kinematic characteristics of the system. In other words, if I drive the actual robot to the end of its working range with the teach pendant, then the computer model in the offline programming package will do the same thing. The simulated robot has the same working range limitations as the real machine. A particular axis stops at its limit the same as it does in the real system.

These 3D models can include the robot and such peripheral equipment as tooling and fixtures (complete with clamps and actuators), positioners (for robotic welding systems), conveyors and pallets (for material handling and palletizing), robot end effectors and grippers, and even safety fencing and other physical barriers. Ideally, all of the peripheral equipment represented in the computer model is identical in size (to scale), shape, and range of motion to the real system.

What Can Offline Programming Software Do?

The model’s basic function is to mimic the system. Accurate modeling allows you to accomplish several things:

  • Perform reach studies—Reach studies often are done during the system design phase to ensure that the system can actually process the desired parts. For example, in a robotic welding cell, it’s crucial to know whether certain welds will be within the reach of the robot. If not, the robot may have to be mounted to a travel track, or the parts loaded into a positioner, to gain access to all the welds.

    Since the simulated robot has the same working range as the real robot, reach studies can also determine certain process parameters, such as whether a particular welding robot can access the weld so that the torch angle is correct during welding.

  • Design system layouts within a factory—System layouts are designed to check and facilitate product flow, determine floor space requirements for the system, or determine the locations of incoming component parts or outgoing conveyors. Since peripheral equipment such as safety fencing, factory walls, and even parts baskets also can be simulated in the offline programming software, very detailed layout work can be achieved.
  • Test fixture designs—Especially in welding applications, fixture design is crucial to the system’s performance, part quality, and weld accessibility. With the software, you can identify interference points for clamps, locators, and actuators and design fixtures accordingly to give the robot access to the welds without compromising fixture functionality.

    For nonwelding systems, the robot’s end effectors can be simulated in the model, thus enabling you to test gripper designs, points of contact with pallets and conveyors, and interference with dies (in the case of press-tending robots) or the tooling and chucks in machining centers (for machine-tending robots).

  • Simulate production and cycle times—Particularly during the quote and build stage, it’s important to know the actual cycle times the robot system can achieve. Some offline programming packages include relatively accurate cycle-time modules that allow true-to-life dry runs in the software to determine what the actual cycle times are. This can be done before the system is even built. Robot vendors often use this function to help provide cycle-time estimates for their customers, but it is also being used more and more by end users to help in their production planning.
  • Offline Programming

    These functions of offline programming technology have been used for many years, especially by the designers and builders of robotic systems, to facilitate the designing and quoting of these systems. Many in the robot world are familiar with these basic functions. However, the word programming in the phrase offline programming is present for a very good reason.

    In the early years offline programming packages were used mostly for the tasks discussed previously. But as time went on, the ability to calibrate the model to the real system, combined with increasing computing power, has made it possible to perform accurate and efficient programming on a PC. True offline programming now can program robots before installation and while they are in production.

    While the robot supplier is building the system, offline programming software can be used to write programs in advance. This greatly reduces the time required to launch a new robotic system after installation. Under normal circumstances, a program is written offline; when the system is built and installed, the program is loaded into the robot. Minor touchups are often necessary, but the overall programming time is greatly reduced.

    For example, in a welding application, less than half the programmed points are actual welding points. These nonwelding programmed points are for air moves, moving the robot from weld to weld. Following offline programming, the air moves themselves rarely need to be tweaked. After the program is downloaded into the actual robot, typically only the programmed points within the welding paths need to be touched up.

    The lifetime of an industrial robot system now easily exceeds 10 to 15 years, so it is quite likely that most companies will reprogram or retool a particular system to accommodate new parts, new product lines, or additional parts perhaps several times during the life of the system. Offline programming allows the programming part of the project to take place while the robots are still in production. Before offline programming came along, the only option was to program on the actual system with a teach pendant in hand, therefore stopping production. Now programs can, at the very least, be roughed in offline, and in the best cases they can be completely written and tested offline.

    Offline Programming and Lean Initiatives

    Lean means lean. No waste. Quick changeover. No lost motions. No unnecessary time spent on tasks that don’t add to the bottom line. What better way to go lean than to use offline programming? Here are some ideas that can contribute to the lean initiatives in your own plant:

    • Offline programming reduces downtime required for programming. This not only makes better use of your equipment (and therefore provides a shorter payback period on capital investments), but also enhances your ability to process smaller lot sizes. By using offline programming in everyday operations, job shops with lot sizes as small as one may minimize the downtime for programming and new part introductions and enhance production.
    • Product design changes can be taken in stride if the programming is done on a PC. For example, often a design change does not require a completely new robot program, but only a few changes to an existing program. If the program in a welding robot requires only a couple of welds to be added or removed, or a bracket or some component moved, then the programming can be done easily offline—even accurately enough, perhaps, that no touchup is needed. Just download the program into the robot and push go!
    • Offline programming systems can be used to optimize cycle times and quality. Without taking the robot out of production, a technician or programmer can watch an existing program run on a PC and take the time to scrutinize it, watching for wasteful things like excess or superfluous air moves. Even modeling the surrounding equipment or barriers can help by revealing how to move pick and drop points (for a material handling system) closer to the robot or closer to the next operation to minimize unproductive air time.

    Calibrating the Computer-Modeled Robot Cell

    What we have discussed so far are relatively common uses for offline programming technology. But there are ways to enhance the usefulness of this software even more and make the most of your time and investment in offline programming software.

    A robot program written on a PC is only as good as the model in the computer. The computer model is supposed to portray the actual system on the floor perfectly, but in most cases, the model is not exactly accurate. If the actual robot system is not set up precisely like the computer model, your programs will be off by that much when you download them into the robot.

    Most users of offline programming software know this and consider that it is necessary to fine-tune or touch up the program after downloading it into the robot. But does it really have to be this way?

    A couple of things can be done to make the programs written offline more closely align with the real world. First, and most obvious, is building the real system exactly like the robot model. But this is far easier said than done. It can sometimes be cost-prohibitive, and in most cases unnecessary, to build a robot system to such tight tolerances.

    A small, standard robot cell may come quite close to the computer model, but the larger or more complicated the equipment becomes, the more difficult it is to build it to match a computer-generated model precisely.

    A good way to compensate for this difference is to calibrate the computer model. This can be done in various ways, and different offline software creators use different means, but the basic process is similar: Write a calibration program on the actual robot, import the program into the offline programming software, and you will be able to see the exact differences. Then the computer model can be adjusted to match the real world more closely.

    In some cases, an exact match still might not be possible. Consider, for example, a large positioner in a robotic welding cell. By calibrating the robot model to the real machine, you might be able to get close, but what if the weldments that comprise the positioner are not perfectly straight? What if the rotary positioner that is manipulating the part was manufactured a fraction of a degree off from the print? When it rotates, it’s not simply a matter of the positioner being in the right place in the computer model; it actually will not rotate precisely around its center of rotation. This is a problem.

    It, too, can be overcome in the computer model with lots of trial and error, but this kind of process can be very time-consuming. It might not be worth the effort, given the other ways to compensate.

    Workarounds

    First, it might be perfectly acceptable to simply touch up every program you create offline and load into the robot. This ought to be a one-time event, so many end users simply figure this into the plan whenever a program is written offline.

    Another workaround is to add searches or vision to the robot cell. This way, even if the program that was written offline is off a little, the searches, tracking, or vision can compensate for what little error remains, making it possible to simply download a program into the robot and run it without touchup.

    Another possibility is to use coordinate systems that are attached to the part you are processing (if you are welding or painting) or the conveyor, table, or other hard interfaces (if you are working with material handling or palletizing robots, for example). This feature essentially attaches a coordinate system to the part you are processing, and the robot program is executed relative to that coordinate system.

    With this type of part-centric coordinate system, even if there are significant discrepancies among the robot and other components of the robot cell and the computer model, the program still executes accurately because it is executing relative to the actual parts being processed.

    Whew! Still with me? This may all sound a bit complicated, and sometimes it is, considering a robotic workcell can have 12 or more axes working simultaneously. The bottom line is that you have ways to compensate for the discrepancies between the machine and the computer model, and the better these discrepancies can be handled, the better the technology works.

    Special Applications

    Offline programming can be used in innovative ways. Case New Holland (CNH) in Fargo, N.D., uses offline programming to identify and fix problem welds in its large chassis-welding cells.

    The plant builds large, high-horsepower agricultural tractors and wheel loaders, and the main chassis for these machines are welded with robots. Some of these programs comprise several thousand lines of code and several hundred welds, so if a program can be written offline, it is a great advantage.

    CNH Fargo also uses offline programming software for troubleshooting and quality control. In the past, if a particular weld was causing problems, it took a while to find the problem weld to fix it. Imagine a four-hour welding program with hundreds of welds and a weld two-thirds through the program is causing the problem.

    Unless the welds are all named, numbered, and easily identifiable, it is not easy to find the problem weld without interrupting production. A robot technician could stand and watch the robot for hours, stopping it when it gets to the problem weld, but that is a waste of time.

    All the welds could be numbered and identified, making it easier to find them in the text of the program, but considering that CNH has dozens of chassis models, and each one has hundreds of welds, it can become very complicated to number every weld. Add to that the reality of design changes and new part introductions and it becomes overwhelming.

    Instead, CNH uses an offline programming package to quickly identify the problem weld visually in the computer model. All programmed points are automatically numbered, so the point number is quickly and easily identified offline. A search function quickly locates the point and places a pause in the program before the problem weld, complete with a note to the robot technician on what to do. All of this takes place in minutes.

    The next time the robot welds that part, it will pause at the problem spot and notify the operator to call the robot technician. This saves hours of time and makes it very easy to not only fix the weld but to catalog problem spots to see if a possible trend is causing the quality problem.

    Continuous Improvement

    Another reason to use offline programming is continuous improvement. In a previous article, “The Pareto principle at work,” I wrote about how many robot users achieve 90% of what a robot is capable of and are satisfied, not realizing that another 10% of capability could be achieved.

    Robot users pay a lot of money for robots. It makes sense to run them in production as much as possible. Downtime for programming or touchups costs money because it interrupts production. If improvements to the program can be made without interrupting production, then that huge robot investment can pay for itself more quickly by gaining that last 10% of capability.

    With offline programming, a robot program can be scrutinized and analyzed offline while the robot continues in production. For example, in a welding application, the torch angles, welding speeds, and air moves between welds all can be studied for wasted motion and possible improvements. Many of these improvements can be made offline so that the next time that program is run on the robot, the changes are in place and the improvements are immediately realized.

    A company using a robot to load and unload sheet steel for a precision shear was able to cut about 20% off the cycle time simply by rearranging the air moves. However, this company did not have offline programming, so all the work was done on the actual robot cell, which meant it was not making parts at the time. With offline programming, most of the work could have been done on a computer, thus saving valuable production time.

    Product Design

    Offline programming software can be used for reach studies, robot access studies, and cell design, thus making new-product introductions and part design more robot-friendly.

    Imagine introducing a new tractor chassis like those manufactured by CNH. By modeling the part and fixture offline, you can address fixturing issues and identify limitations even before the equipment is built. It is not necessary to take the robot out of production for testing and reach studies on pilot parts, because the offline programming package can model the robot, part, and fixture accurately enough to assist in the part and fixture design.

    This software easily can show where tooling interferences might occur, where the robot will have difficulty reaching certain welds, and even suggest part design changes to make the part more robot-weldable.

    These examples illustrate how offline programming software is not just for offline programming anymore. Many tasks that once required actual trial and error on the robot itself now can be accomplished on a computer, saving time and keeping the robot in production. The only real limit is your imagination.

    What could you do with an accurate 3D working computer model of your robotic cell? Oh, the places you’ll go!