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.
You paint "engineers" with a very broad brush. I, for one, reject your argument & your thesis. I have been practicing the art & science of electro-mechanical design engineering for the better part of 50 years, and I can assure you that in every company that I've been employed, ALL the (degreed) engineers were VERY intimately knowledge of EVERY piece of equipment or product that left their cubicle & went into production. And, EVERY engineer was directly responsible for EVERY shred of paper relevant to the project. Now, this was true in my experience whether the company had 2 engineers or 22 engineers! And, I can further assure you that EVERY engineer in every environment also had a toolbox w/ all sorts of "goodies" packed into them. Not one fellow engineer was an "Ivory Tower" fellow, who had only two items.... his slide rule & a pencil sharpener!!!!
I am not an Engineer. I am an Electronics Technician. What this generally means its that I get stuck with the stuff an engineer screwed up and have to make it work anyways, after engineering has used up all the time for the job. It has happened many times. The engineers have been told how important they are. They are rather well paid. But it comes down to some poor sap who has to get the product working when the delivery date has already been missed because the engineers didn't get their part done on time.
Delivery date is 12 weeks out. Assembly and testing will take 3 weeks. Any special parts will need to be orderred no later than 6 weeks out. So, Engineering comes out at 10 weeks and decides all this is rush because they waited until 8 weeks to figure out what was going to change to meet the customers requirements (which had been decided 6 MONTHS ago) and so the special parts won't be in until week 13. But it is the shops fault that the machine is late even though the engineers didn't have ANYTHING ready until week 10 of 12.
The person with the least control over the project is often the one with the most responsibility dumped on them. And could have probably had the new requirements designed at week 2 because he actually has to work with the finished product and the customer.
Yeah, I tend to (well HATE may be a bit strong...) dislike many engineers because they are so far removed from the final product that they don't seem to have much of an idea what is really involved in executing the idea. It works on paper...
Better treat the Engineering TECHNOLOGISTS with a lot of respect as they are generally the ones who find and solve the problem while engineering rides off on their white horses to joust with another windmill...
We can start talking trash about all EEs who inccurred emergent software hacks by failing to understand the complete system that their assigned module fit into.
2. Reminds me of a similar costly scenario I was involved in years ago, where the production mgt refused to buy the right sized (power) screwdriver for the line. Result, the screws didn't get torqued in enough, and the company paid dearly for material, labor and more while pursuing field replacements. And, yes, here too, an urgent SW hack was required to keep misbuilt hardware from doing bad things -- while still operating correctly -- until the equipment could be attended to.
3. I'm intrigued, hopefully without being nosy, about where and how the certain intransigent individual fit in things. A bean counter imported into production control? An design/production engineer who'd done great things back in the day, but having been promoted out of that scene persisted in "his way or the highway" control over his old venue? Some firebrand climber recruited from outside who wasn't going to risk slipping budget or deadlines, or crossing lines of normative behavior in order to keep his/her career on track?
Have you ever noticed how management, with the wisdom of King Solomon, often decides to adopt half a solution, without realizing that half of a solution isn't a solution, it's just another problem?
Have you noticed that it's nearly always the electrical/electronic engineer that rides to the rescue of the management or even the mechanical engineers? How many times do the mechanics solve a problem in our electronics? It's been the story of my life in engineering :-)
From Dell / Intel® New Paradigms in Design Work Scott Hamilton, vertical market strategist for Dell Precision workstations, 5/2/2013 3
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 ...
A quick look into the merger of two powerhouse 3D printing OEMs and the new leader in rapid prototyping solutions, Stratasys. The industrial revolution is now led by 3D printing and engineers are given the opportunity to fully maximize their design capabilities, reduce their time-to-market and functionally test prototypes cheaper, faster and easier. Bruce Bradshaw, Director of Marketing in North America, will explore the large product offering and variety of materials that will help CAD designers articulate their product design with actual, physical prototypes. This broadcast will dive deep into technical information including application specific stories from real world customers and their experiences with 3D printing. 3D Printing is
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
12 
