Earlier in my career, I worked on a project that integrated a robotic body-welding line for Ford Motor Company. In those days, Ford used Kawasaki robots almost exclusively. They had a fixed hardware and software interface standard for each type of robot with a long and storied history.
My project began with an attempt to sell Ford on using a different, better (but more expensive) brand of robot, and a better (but again, more expensive) pinch-welding "gun." This process proceeded apace until about the 11th hour, when suddenly some intransigence from one particular individual at Ford suddenly forced everyone to drop the original plan, cancel the original hardware orders, and order Kawasaki robots. (The better weld guns, however, were kept.)
As the designated shop-floor "robot guy" for this project, I became involved after all the hardware components had arrived, had been uncrated, and were being assembled. Innocent of the consequences of this project's sordid history, I sailed blithely into the mess and set about putting together the various bits and pieces, as I had done many times already in my short career.
It didn't take very long to discover a serious problem.
Back then, the very old, set-in-stone, Ford/Kawasaki standard used a single multi-conductor cable to carry discrete I/O signals (24V DC and even, in some cases 120V AC) from the robot cabinet, through the weld controller, and out to the weld gun. For those of you not familiar with the term, a weld "gun" is the "pinching" bit that you see in movies like Minority Report, or any PBS special about the automotive industry. We encountered our problem when we attempted to wire up the new weld guns to the old cable.
The old cable provided only two signal wires for closing the pneumatic valves that operated the weld gun. The new weld gun required four wires. And the kicker was that although the Ford/Kawasaki standard had provided for several spare wires in its youth, feature creep over the ensuing years had whittled the number of spare wires down to one.
Before calling upstairs to the design engineers responsible for this strange turn of events, I pulled all the electrical drawings: the gun, the weld controller, and the Ford/Kawasaki interface that the Kawasaki robots had been delivered with. I discovered that they didn't match. It wasn't that I was overlooking something. No, this oversight had happened in the design phase, long before I ever got involved.
It wasn't hard to figure out what had happened: When Ford had demanded the last-minute switch to their standard Kawasaki robot, the controls engineers had simply swapped the electrical drawings without thinking about the fact that the weld guns were not the same units that the standard had been designed around.
I can agree with this one wholeheartedly. It's amazing to me how engineering "types", myself included, get to solve and / or fix a great number of problems created by 1.) Budgetary restraints, 2.) Management, generally non-technical management, 3.) Extremely short time frames, 4.) "The boys in engineering will handle that" mentality, 5.) That's not my responsibility, etc etc. Luckily, this problem could be addressed and solved. Some cannot and with this being the case, the poor engineer and / or technician usually takes it on the chin. My career spans about 40 years; 1966 to present day and this seems to never change. Some how, "technical types" are expected to have all of the answers. In a perfect world, this would not happen.
Gee, I just started a commotion here last week with an email that was about the same kind'a assumptions of compatibility being made. The Ford robot replacement screw-up example is on a much grander scale, and immensely more expensive to resolve I'm sure. Still... this stuff happens at all levels.
Remember the Mars Lander where metric and standard were switched, or not switched as the case may be. When I talked to our Managing Quality Engineer Thursday about some non-updated duel use prints that I had been asked to make a fixture to match, and a separate inaccurate mass callout for the fixture that could have created havoc with our test equipment... My input was simple.
Get everybody on the same page.
And hey TunaFish... We had a situation arise here a couple years ago where someone pulled the torque rating for a standard 1.5D thread engagement for a steel screw and nut but applied that to a thin tapped copper bus bar with about 3 threads.
They didn't catch it until a whole day's worth of those units was messed up... because not every one of them was stripping outright. They thought it was the tapped bus bars' fault until someone checked the recommended torque for 3 threads in copper...
I can not recall any story that has brought forth so much finger pointing and downright braggadocio. In the old days we called it, "Doing our job". The whole story that started this string was about rigging incorrect items to perform a function at a level below what they should perform. That should have triggered a response to purchasing to get the right equipment: end of story. Instead the company has been left with items that are probably unrepairable and ill preforming. Who cares if it was a degreed engineer, a technician or a passing janitor. Enough of the name calling.
Every company is set up with different levels of responsibility and we are all over worked and under paid. This whole discussion turned into who could tell the biggest tale first. We all have jobs to do and probably do them to our best ability and with pride. And I would be willing to bet everyone reading this has commited at least one error, who somebody else had to fix and could be the subject of a new story.
Vyper3000; As a former electro-mechanical technologist, and now a journeyman electrician and millwright, I have had my share of run-ins with electrical engineers, mechanical engineers, salesmen, saleswomen, managers, and even other electricians and millwrights. The bottom line that I go by is: If I fixed the problem, I get to say what the problem was. And in Automotive especially, I have seen a lot of incompetence in engineers promoted to senior positions.
There certainly is a wide spread of experiences that different folks have had with different engineer attitudes. Unfortunately the field has produced a few "Prima Donnas", but they are not representative of the whole herd, trust me on that. Just like preachers and teachers, there are all kinds.
I have always held that the way to be a good engineer is to have some level of competence in all of the areas that your overall product includes. That is the way that the software designer can understand the molding issues when the code winds up needing another memory chip, and the PCB thus needs to grow a bit. I also believe that engineers must be able to repair the products they design, at least a few of them. Not only does that provide insights toward improving reliability, but it also serves to provide an understanding about serviceability. And as for those organizations that design products that should be repairable but are not: I Hope you go broke! OUt of business! Closed down for good!
About those who neglected to verify that the previous design would support the new hardware, it would not hurt them at all to spend a few shifts putting new cables on those robots. Generally there is lots of room to work on the third maintenance shift. And it is a great education.
From Dell / Intel® New Paradigms in Design Work Scott Hamilton, vertical market strategist for Dell Precision workstations, 5/2/2013 5
Early in my career, I worked as a draftsman and remember the days of drawing on vellum with numbered pencils and Mylar with plastic lead. This was a fun experience in the sense that I ...
I've been using workstations for more than 10 years and love finding ways to get more performance from my system. With demanding professional applications that require more power each ...
A lasting memory from my first job as an engineer in an auto assembly plant is standing on hard concrete at six in the morning, vending-machine coffee clutched in hand, listening to ...
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 radio show will show what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.
To save this item to your list of favorite Design News content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
7 
