Oh, the places you’ll go with offline programming—Part II
Having difficulty aligning your offline programs with your real-world robot? Then you’ll want to read this article that discusses ways to overcome this problem, along with other offline programming uses that can help you get the most from your robots.
Part I of this article explained the basics of offline programming for robotic manufacturing cells, as well as some of the advantages of the technology that may be less obvious. This concluding part discusses the process of calibrating the robot model represented in the offline software and then gives some examples of special applications in which offline programming software is being used.
Calibrating the Computer-modeled Robot Cell
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.
Now, 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 to build a robot system to such tight tolerances, and in most cases unnecessary.
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 actually 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.
This, 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.
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 actually 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). Not all robot manufacturers offer this feature that 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 between 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 it sometimes is considering a robotic workcell can have as many as 10, 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.
Offline programming can be used in innovative ways. Case New Holland (CNH) in Fargo, N.D., uses offline programming as a method of identifying and fixing 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 all 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 particular 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.
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 percent of what a robot is capable of and are satisfied, not realizing that another 10 percent of productivity 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 percent 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 particular 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 percent 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.
Part I of this article touched on using offline programming to design products, but the information is worth repeating. 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 3-D working computer model of your robotic cell? Oh, the places you’ll go!