I read the by-line and immediately thought, "Another story about running a robot slow to keep it from wearing out or breaking." But it seems your isue was the timing of the weld gun in relation to the robot motion.
But to my first point, I have always wondered why technicians (most notably the maintenance guys) want to run a robot (servo robot no less) at a greatly reduced speed? I understand that end of arm tooling weight has some factor in this, but if the robot program allows you to run fast, then I expect the robot to be designed to handle this speed. If it wears out or breaks, that is the manufacturer of the robot issue. I figure if the manufacturer didn't want it to fall apart from running fast, they should of limited the maximum speed that I can set!
Actually, that makes perfect sense, GTOlover. If it's made to run fast, it should certainly do well running fast. At the manufacturing show in Philly last month, I saw some robots that moved mind-numbingly fast.
I've seen some of the same robots at shows, Rob, and I'm always amazed by the speed. I'm also a little baffled. High speeds combined with heavy end-of-arm tooling combines to apply some pretty big bending moments and torques, which I would imagine puts a lot of wear and tear on the robots.
GTO lover; End of arm tooling - weight and robustness - are factors to consider. There are two competing parameters: speed and acceleration. A short, fast move with high acceleration can be hard on tooling, and if you are moving a part, the part can shift or even come out of the gripper. Even if there is a problem with a misplaced part only 1% of the time, the extra cycle time of a slower move can be more than paid-back by 100% successful placement vs. stopping the line to fix the part. Reduced acceleration limits the maximum speed that can be reached in a short move. Another issue is cycle time. If the longest cycle time in a series process is 50 seconds, there is nothing to be gained by completing previous or following steps in 30 seconds by driving the robot at maximum speed.
Being the snide, recalcitrant, irrascible OLD_CURMUDGEON that I am, I have a completely different take on this...... The "readjustment" of the operating parameters of the robot may have had nothing to do with the throughput of the production line, BUT may have been inspired by some "union" action. Obviously, the company wherein this incident occurred was of sufficiently high capacity to warrant robotic technology, AND many of these companies also "enjoy" organized labor representation. Just sayin'............
Old Curmudgeon; You have struck a sore point. The 'technician' that changed the termination type and was patting himself on the back was one of two self-proclaimed 'robotic welding experts'. Neither was competent, let alone proficient at robot programming or welding applications. They were Managers, not union, Several times I had to fix their mistakes - which they did not even realize were mistakes. A robot does not just do what it is programmed to do - it does EXACTLY what it is programmed to do. A common mistake is programming a joint move followed by a linear move. When stepping backward the robot moves in joint, and does not re-trace the linear path. I have seen many programmers baffled by this fact.
Glenna: Not witnessing this event, I have no direct knowledge of all the parameters that went into the situation causing the failure. However, that being said, I have been employed by two very successful private electronics businesses in my long career, which were non-affiliated for many years, and then became unionized. And, in each case, these companies suffered drastically to the point of death. While the initial explanations didn't point to the unionizations as the culprits, history did show that it WAS the fundamental reason for their demises, sorry to say. The shame of it all is that IF it weren't so, and all else being equal, I could have envisioned myself getting that proverbial "gold watch" after 50 years of dedicated service.
Furthermore, I have designed enough electromechanical devices in my career to understand the importance of component specifications, and why writing "cautious" software to control these devices is UTMOST important! As others have blogged so learnedly, acceleration, deceleration, impact & momentive forces MUST be held in high priority in all designs.
All through the 1970's I was an Elec-tech at Burgmaster, a company that made turret drills, with NC programming. We tried designing and building a vertical spindle mill, with tool changer for a 3 axis CNC, as the CNC was just getting started in Machine Programming. The enginerrs did a nice job on the mechanics of the tool changer,but didn't allow ramping up/down for the accelleration at end of cycle, many tools got tossed from the gripper and sent flying.
I'd have thought they'd incorporate ramping in the toll changer arm, as all the X-Y-Z axis had .400" ramping from max speed to final position commanded.
Just as jackrabbit starts can quickly wear out an automobile, running ANY machinery the same way has the same effect. Although the robot (or servomotor etc) may be rated for some top speed, you need enough time to reach that speed and decelerate safely. It costs power (and heat) to spped up and that energy needsa to be recovered (usually as heat) to stop. The best advice was given in another reply, don't make the process any faster than the limiting factor (the longest process in a serial chain). The bragging rights you'd get from having the fastest robot will quickly go sour when you have to repair your cell prematurely ! As far as the robot being "designed to handle this speed".. please refer to the "Designed by Monkeys" column for enlightenment.
My wife used to run a machine that assembled IC sockets from boxes of plastic bodies and bags of pins, producing about 100,000 sockets per shift. There was an employee incentive program that awarded $.25/hr to the operator that held the highest production record each week. The formula for production record was the number of good sockets produced minus the number of bad sockets produced. If you let the machine run out of components it made fewer parts which cost you points. If you let the machine get dirty or drift out of adjustment it produced bad parts which cost you points twice.
For several years she and the other operators jockeyed for production records. Every so often they would improve the machine to run faster or more reliably which would bump the production standings a bit. One day they made an "improvement" to the machine that made it run much faster, but the count of bad parts skyrocketed. When asked when they were going to fix their fix the operators were told that count of bad parts had been so low for so long that they didn't bother with them anymore. The faster machine made more good parts per hour and that was all that mattered.
My wife happened to hold the production record at the time the machines were "improved" so with the new higher bad part counts no one could ever beat her old record and she kept the $.25/hr bonus for several more years. The incentive program no longer produced healthy competition but animosity instead. Eventually when a wave of layoffs came she was let go because she was costing the company more money for the same job.
"I figure if the manufacturer didn't want it to fall apart from running fast, they should of limited the maximum speed that I can set!". First, speed isn't directly the issue: it's the acceleration and jerk required to get up to speed and down again; obviously, you can do a long motion at a high speed with relatively low acceleration but a short motion requires higher acceleration. Also, acceleration is the result of applying a force to a mass as well as other opposing forces. It is mostly the force required to produce a desired acceleration that resolves into stress in the various mechanical parts producing wear out; this is a complex function of payload, tool-point vectors, drag and other factors that are very application specific. No one would be happy if manufacturers set performance limits at the 'safe' value for the most demanding application conceivable. No one would by a car if the speed was restricted to a safe value for parallel parking. Also, schools of practice such as TPM and OEE recognize that wear always happens; the economic solution is to balance costs of maintenance and downtime against productivity. Factors like utilization play into this: even the same robot doing the same job will have significantly different service requirements if producing 1000 parts per week versus 100,000 parts per week. What you do with a robot is an economic as well as technical decision. Also, any multiaxis robot is in some ways its own payload. While the mass of all subsequent links must be accelerated by an axis, the reaction force of the relative motion of all subsequent axes must also be overcome as the reaction force of each axis supporting it must be overcome; consequently, the amount of force acting and the amount of resulting stress is very much a result of tool trajectories which are ever so application specific. Keep in mind that for any revolute link, even constant velocity implies centripetal acceleration. Additionally, there is thermal stress on the drive system to consider: short bursts of high effort may be possible without elevating the temperature of motors and bearings so the peak dynamic limits are also a function of duty cycle. Applying robots in manufacturing is not, as you wish, child's play. On the other hand, maintenance guys are right to restrict the feeds and speeds to only what is necessary to meet production capacity with the least effort and the highest yield possible which translates into least operating costs for the equipment. Never forget that the purpose of an industrial robot is to maximize profit.
I understand all that and agree. But in injection molding the time the robot goes into and out of the tool has to be minimized. My comment was in that venue in that this is a critical time delay for the cycle time for the next molded part. After the robot has the part and is clear of the molding machine, I always optimize the robot to match the press cycle (slow it down). What got me was that technicians would slow down the overall speed parameter and the entire robot maximum speed would be inhibited, thus impacting cycle time. instead i would argue to maximize the overall speed and then slow down individual moves non-critical to press cycle time. Always with the intent that the end of arm tooling was robustly designed and within the payload capacity specified by the robot manufacturer.
And in no way did I imply that this was "child's play".
I have to admit that some EOTs (end of tooling) over-loaded the robot and the speed and accelerations had to be adjusted downward. But this was usually a top candidate to redesign EOT or split the EOT requirements.
This story reveals a few common problems. First, software is invisible, you can't have too much version control and modern data driven / object oriented controls are more vulnerable as the relationship between a data value and its effect on controls is often not obvious. I once looked into a problem on an old piece of equipment that was experiencing occasional misfeeds and discovered that someone had changed the I/O configuration to use the wrong sensor as a process input (cases of nobody changed anything are fairly frequent: Nobody is a busy boy). The second important point is that time is money: the practices of OEE and TPM reflect the dark side which is that the faster a mechanical system goes the faster it breaks down. This is an exponential property. I frequently have to explain why the OEE rate factor must not exceed 100% (why you should not give yourself bonus points on operating a system beyond its design limits). Wear out behavior in general is at least inverse cubic with cycle time or worse when mechanical limits are exceeded (fasteners break out, shaft couplers slip, shafts break). The corallary of this is that mechanisms always wear out. For positioning systems, the limit is when the required precision can no longer be obtained which can be well before any obvious mechanical problem arises. The third thing is that it is difficult to specify the performance limits of a complex articulated mechanism such as a welding robot. While the datasheet calls out maximum reach, payload and dynamics, these parameters are for some arbitrary case and it is typically not reasonable to max out everything at once. What the specs rarely reveal are parameters like stifness, maximum payload angular moments, and power dissipation capacity which all have bearing on how hard and fast you should go. I once experienced a case where a 1-1/4" steel spline shaft supporting a robot grip would snap off every 50,000 part cycles. By design, the robot was carrying the maximum spec load at maximum axis extension at maximum acceleration while translating and rotating simultaneously (the fix was to lower the robot base by ~100 mm). A corollary is that parameters are typically spec'd independently while during complex motions the acceleration of outer links imposes an additional load on inner links. The fourth point is that welding robots (an other applications) have difficult to quantify and nonlinear loads imposed by attached hoses and cables. This is easy to ignore and difficult to properly compensate. The classic error is to assume that if the extra weight is supported that nulling weight also nulls mass (it doesn't). The fifth thing pointed out by this post is that static behavior as seen by walking through tool paths is a nearly meaningless representation of dynamic behavior (at speed everything is ballistic).
Thanks Glenn for sharing such an informative article. It is a clear illustration of the fact that in industry speed of operation is not only important but the program should be accurate as well. So the speed of the operations have to be compromised otherwise they might lead to the production of defected parts or may also lead to breaking of the machine and its tools as mentioned in the article.
Having actually been a robot programmer in my previous job, I'm annoyed at two robots at my current plant. They are ABB robots, and as the original article stated, if you set the accuracy parameter very high for a move, the robot goes to that exact point before performing the next instruction. That is very important for something like making a spot weld, but when the points are just midpoints in a series of moves to reach a final destination, it gives the robot very jerky movements.
I was taught by an ABB guy to lower the accuracy setting for those midpoint moves to make the movement smoother, but apparently the company who programmed these two robots never learned that lesson, and it bothers me to see the robots having such jerky movements when I know that they don't have to.
We did learn about the precise stop versus the direction changing intermediate move and we learned about acceleration and decelerations during moves. So there are ways to speed up cycles without a lot of stress. None of it is trivial, although the process is straightforward. But some times it is possible to reduce the precision and speed things up even more, but only when accuracy is less critical. After all, not every operation demands high precision. But that should only be done by those who understand the product very well.
after my work in supercomputers, I used my digital to analog experience in Robotics, both in AGVs and tracking devices for parolees.
One of the hardest problems to solve is how do you control motion in a 5000# AVG without making it too slow or so fast it damages it's hardware.
Knowing how PWM controlled motors act to ramp-up and ramp down is critical and THEORY VS REALITY is very important.
As in supercomputer design, you must test and get the repeatable motions in places to get the parameters for proper program code to program the PWM motor controllers....the real problem is that AGVs MUST have a HARDWARE EMERGENCY STOP SYSTEM that is not dependent on other progrmming.
To make the AGV work, a default servomechanical wheel brake was put on the driven wheel(s). The bad news: a stop from full speed created a flat spot on the driven wheels and we could never get a full stop in the 5' requirement for AGVs.
( the boss gave us that requipement )
What we finally did was to set up a guided " racetrack " in the parking lot to test maximum speed before guidance loss ( around 7.5MPH ) due to feedback overcorrection and maximum rate of travel when the safety overrides were triggered.
With those real world parameters set, we could make the AGV safe and controllable for the next step: proper motion of the servo arm to handle explosive airbag triggers...
Very informative post Glenn. Two years ago I experienced a fairly similar situation with one client. The robot (Janome --SCARA ) dispensed an adhesive onto a metal substrate; i.e. control panel. After application of the adhesive a decorative trim piece was placed onto the panel. This will be hard to believe but, the entire work cell was a cost center in which the employees received a base salary and paid a bonus based upon daily production. (By now you know where I'm going. ) One interprising individual felt the need to "speed things up" a bit so he altered all speeds for each path the robot was programmed to take. We were negligent in not blocking access to the program but qute frankly we did not realize anyone in the cell could (or would ) make adjustments. Boy were we incorrect about this one. We fried two servo motors -- down for over a week waiting on replacements and cost our client well over $2K for replacement parts.
Glenn, I used to be a machinist and most of the parts I made were welding tips and adaptors for robotic welding arms. One day I came in and my so-smart supervisor had cranked up the cycle time on the parts. I was all for reducing cycle time when appropiate, but his parts were junk in comparison to what we were making. I stopped that right away. I can't imagine what our buyers would have thought if we just went from sending them perfect parts to half-assed junk parts. I don't know what he was thinking. It's one thing to save time, but at what cost. They bought from us for a reason, and it sure wasn't because we made junk like he was making. The parts were tapered adapters. Our tapers were smooth and glossy...perfect. The ones he was making were so jagged they looked like the type of connection that you'd plug an air line into to hold it in place. All stepped. I think they MAY have noticed the difference! We always strived to make parts faster and faster(us machinists), but we never waivered on quality to do it.
In an age of globalization and rapid changes through scientific progress, two of our societies' (and economies') main concerns are to satisfy the needs and wishes of the individual and to save precious resources. Cloud computing caters to both of these.
For industrial control applications, or even a simple assembly line, that machine can go almost 24/7 without a break. But what happens when the task is a little more complex? That’s where the “smart” machine would come in. The smart machine is one that has some simple (or complex in some cases) processing capability to be able to adapt to changing conditions. Such machines are suited for a host of applications, including automotive, aerospace, defense, medical, computers and electronics, telecommunications, consumer goods, and so on. This discussion will examine what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.