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.
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.
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.
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...
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.
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.
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.
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.
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.
Festo's BionicKangaroo combines pneumatic and electrical drive technology, plus very precise controls and condition monitoring. Like a real kangaroo, the BionicKangaroo robot harvests the kinetic energy of each takeoff and immediately uses it to power the next jump.
Design News and Digi-Key presents: Creating & Testing Your First RTOS Application Using MQX, a crash course that will look at defining a project, selecting a target processor, blocking code, defining tasks, completing code, and debugging.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.