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.
We're seen this type of management problem a couple times in recent Made by Monkeys postings. It's quite surprising that management would shrug off -- or refuse to accept -- solutiuons presented by engineers. This seems to be more than just a communications problem.
Rob, I have to agree to a point. When large coprporations set up quality systems of processes and procedures, changes become rigid and inflexible to the point that many people do not want to do the work to make any change (even when it is benefical). I have worked at a large manufacturing facility that it was nearly impossible to upgrade a simple proximity sensor. Then I worked at a small shop that I could completely re-engineer a robot cell with little resistance!
However, it would seem that this change should of been a worth while if it prolongs the servo motors life.
You're right GTOlover, once a procedure is approved in an ISO company, it's really hard to get the procedure to change. If this is a component part that is shipped to another company they may need to go through the qualification process all over again.
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."
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.
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.
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.
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.
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.
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.