While I worked for ABB Flexible Automation, I provided support for ABB robots at the General Motors Oshawa Truck Plant, GMT 800 project. Part of the preventive maintenance at the plant was using a thermal imager to look for hot spots. A hot spot could include a loose electrical connection. During an inspection, they found one of the robots had hot servo motors. I was tasked to find out what was wrong with the robot and fix it.
During my investigation I found that the resistance welding gun the robot was carrying exceeded the rated payload. The perch position was programmed so that the minor axes -- the wrist axes, 4, 5, 6 -- were holding the weld gun at an awkward angle, causing each axis to carry a load against gravity. These three axes had the high temperatures. The servo-on time was set to maximum, effectively years. The robot would wait with the servos on, for years, before timing out, enabling the brakes, and turning off the servo power.
I presented these finding to the engineer in charge of that work cell. The options to get the servo motors to run cooler included:
Reduce the weight of the weld gun to within the payload specification of the robot.
Replace the robot with a higher-payload unit to match the weight of the weld gun.
Change the perch position so that the wrist axes were not carrying a load. This could be done by removing the servo-on signal, causing the servo motors to power off, and the brakes to engage. Then release the brakes of the wrist axes, allowing the weld gun to hang in an orientation that would not load the wrist servo motors, and re-teach the perch position.
Change the servo time out to minutes, allowing the servo motors to turn off and the brakes to engage. This would cost a few milliseconds of cycle time each time the servo system was enabled and the brakes released.
Each of these options was rejected. When I was asked again about the hot servo motors, my response was that if they were not willing to accept any of the options, they would continue to have hot motors.
Tell us your experiences with Monkey-designed products. Send stories to Rob Spiegel for Made by Monkeys.
My favorite justification for this type of decision making was provided to me at my first job. "We can't change the design now.....We've got a lot of experience with the hardware." My boss was a brave and brilliant man, a PhD Mechanical Engineer, whose response to that was, "Yeah, but most of it is bad......"
"The trick he would use was to only work verbally (that way he could remember it any way he wanted). "
Hahaha, Harry was the same way. One of my colleague's favorite stories was the time Harry was doing his usual arm waving and saying the problem was this or that. My friend pulled out a pocket recorder, held it in front of Harry's face, clicked it on and said, "Please repeat that so I get it right." Harry just sputtered and refused to say anything else.
Unfortunately we did not have an e-mail system or correspondance repository or we would have tried to CYA with paper.
They used to have trouble doing estimates until I offered to create an Excel spreadsheet to automate the process. I discovered the problem. Every time I'd go back and ask for clarification of their method for estimating a piece of equipment, I'd get a different answer and frequently from the same person.
BrainiacV (AKA McGyver ;), Your story reminded me of a similar experience I had with a PM who was known for throwing his Engineer's under the bus (when his bad decisions came to roost). He tried it with me a few times, but I quickly (and I do mean immediately) responded with paper and Email trails each time. He quickly stopped trying that with me (though he got a few people fired along the way including, ultimately, himself).
The trick he would use was to only work verbally (that way he could remember it any way he wanted). But the trick I countered with was I would always follow any verbal conversation with an Email (usually disguised as a request for clarification or agreement).
It's unfortunate, but knowing how to CYA is a necessary skill for any Engineer.
Don Quixote, I used to work with a hardware manager that we called Harry Houdini. He could get out of anything. We had a project with a tight time line and he told me to work on just a segment of it so we'd have at least something done. Later in a meeting explaining our project progress, he threw me under the bus claiming that we needed a little bit of everything done instead of concentrating on just one small section I had worked on.
I didn't care, I had given my notice and he was obviously going to use me as the scapegoat as to why the project was not keeping to schedule. I had been warned by others that he would never take responsibility for his management decisions.
Sorry, your nick name just triggered a "that reminds me" moment.
I once worked with an engineer at my first engineering job who was very bright and an excellent mentor. Then he got promoted into management and things went south, especially his judgement. I once heard him say that his decision making was easier when he was, "unencumbered by knowledge." I left shortly thereafter and heard through the grapevine that he was demoted back into staff engineering. But, due to his previous behavior, didn't have a lot of friends.
They found the issue and then requested this person to investigate it. So it was not like he was offering unsolicited advice. If you are not willing to make any changes, then don't waste my valuable time on the problem.
As an Engineer that was nick-named Don Quixote by his boss (on more than one occasion), I can sympathize. Having fought (and lost) many battles, I (still) try to choose my battles wisely.
But, playing devils advocate, if it's working (producing in-spec parts on schedule) but runs hot, perhaps the bureaucratic machinery can handle replacing failed components easier than fixing a non-optimum situation. Often the true cost of changes are hidden (such changes can run tens of thousands of dollars, where as perhaps replacing a servo might cost a hundred's and is already rolled up in attrition budgets).
Communication runs both ways. I'm still on the non-management side but I underdstand that you need to understand "their" point of view to strategically pick your battles well.
Rob, I think the answer they wanted was, "Everything's fine. Don't worry about it." I used to have a boss who always said, "I don't like negativity." Of course, he always got the answers he wanted, which always boiled down to, "Everything's great."
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.