<<  <  Page 3/3
User Rank
MY two cents ...
OLD_CURMUDGEON   10/11/2013 11:12:18 AM
Several posts suggested not enough information to truly solve the problem.  I agree.  No matter HOW detailed the author was in describing this machine's functions, seeing it in person would have yielded an infinite more information about the action. 

That being said, I have long held this position....  We all no doubt have heard the expression, "A picture is worth a thousand words."  Well, I've added my own corollary to that axiom, "...... AND, the REAL thing IS worth a thousand pictures!"

I believe this applies to THIS problem, and to so many others, too numerous to count, in our daily interface called "life"!


User Rank
Re: Seeing is (most of the time) believing
GTOlover   10/11/2013 10:55:03 AM
Hank, I would agree that the person watching the equipment probably had a working knowledge of what he was seeing and what was supposed to be happening. The armchair engineer probably is relying on the design intent and initial testing to back up his claim.

I can recall in my earlier days working on a piece of automation that inserted filters into a charcoal canister. The robot then moved the part onto an ultrasonic horn to seal the filter into the canister. After release into production, it was discovered that the robot would try to place a canister on top of a canister causing a catastrophic failure that required a rebuild of end-of-arm tooling. We contacted the automation vendor and they assured us that it was impossible as the system had redundant sensors. And it seemed that they were correct as we could never repeat the crash. Not more than a week later, repeat.

All I can say is that we were correct and the automation engineer had to eat humble pie! It was a logic error if the machine was e-stopped during a certain robot move and the operator manually loaded the canister and restarted the machine. The robot was too stupid to know that outside intervention occured and ignored the sensors during the subsequent recovery move! The fix was actually quite easy, we made the robot smarter!

That said, listen to the guy in the field and expect the unexpected! Better to be wrong and found the problem than to be right and hindered the solution. Seems the latter prevailed in this story.

User Rank
Seeing is (most of the time) believing
Hank-4   10/11/2013 10:28:55 AM
I agree with some of the posts that it is really difficult to read the story and make a guess at which one of these engineers is right. I have been servicing analytical iinstruments for 40 years and am always amazed at the number of ways that even relatively simple instruments can screw up. That being said, if I were forced to pick a side, I would side with the engineer who is actually onsite watching what is happening.

The first question that "we analysts" should ask is, " how familiar with the machine was the engineer on site ... did he know exactly what components were supposed to be activated during initialization ... did he have a service manual?" It seems a bit far fetched to me that any management with walking around sense would send an engineer to fix a system with which he was totally unfamiliar. Such practice is unlikely to make a very favorable impression on the customer.

A set of questions should also be asked, regarding the engineer who was sitting in his chair passing judgement on the engineer in the field. Did he design the machine? Did he know ALL if the possible failure modes of the servo control system? I'm guessing that the answer to both of those questions is probably "no".




User Rank
It's the 'Over the wall' syndrome
greenewr   10/11/2013 10:11:51 AM
This sort of interaction crops up in many places.  I've worked electronic hardware design and software design and there is the exact analog of this story:  It's not my problem it's yours.  Finding the root cause is what's needed; without preconcieved notions on either side.  I (in a software capacity) have been absolutely convinced that the problem was a hardware one, just to find the bug later.  The converse is also true in that I've been informed (blamed) for a failure and have proved that the failure was in hardware.  An open mind till the root cause is found will help anyone be a better troubleshooter.

User Rank
Who knows, not even Bo
Noswad   10/11/2013 9:39:50 AM
How are we supposed to know? I am not familiar with the machine. I don't have a manual. I have not visually inspected the machine to know how it is supposed to operate. We don't have enough details to give a decent answer. Not a very well written story and a dumb question to ask with such few details.

Ken E.
User Rank
Logic, or assumptions?
Ken E.   10/11/2013 9:19:46 AM

I think the only correct answer to that question is 'How could we possibly know?'  It's even possible they were both right, or wrong.

Unfortunately, in my experience, engineers tend to take assumption shortcuts all the time, and suffer disproportionately from Male Answer Syndrome, and it's cousin, Cliff Clavin Disease. 

When it's within an area of expertese, this might be OK, and indeed that Senior Engineer (I confess, I am one.) may have known something the young pipsqueak didn't.  What was wrong, is that he sat on the throne of his authority and experience pontificating instead of seizing this as the learning or teaching moment it certainly was.

Don't assume that because you know a lot about something, that you know a lot about everything.  It's a struggle to be patient when you are as smart as us, but there is a payoff, sometimes we even learn new things.  This might sound overly pious, but I assure you, I see myself in this story.

User Rank
Observe vs. jump to conclusion
GlennA   10/10/2013 7:55:44 PM
I don't think it is a young vs. old, or new vs. experienced, rather observing and paying attention, vs. jumping to conclusions.  Experienced engineers may be more likely to think they have seen the problem and jump to a diagnosis, but an inexperienced 'hot-shot' may do the same thing.

User Rank
Been there, had that done to me
armorris   10/10/2013 9:50:25 AM
I told a similar story in an earlier Sherlock Ohms post. I was a young engineer, just out of college. When I told my boss what the problem was, he didn't believe me. It was the last straw and I quit, because by boss called me incompetent. I imagine that they eventually had somebody rewire the panel in "rats-nest" style, like the others.

User Rank
Insight for the Older Engineers
tekochip   10/10/2013 9:07:22 AM
This seems to be a reoccurring them in the Sherlock Ohms stories; the young, bright engineer finds a problem and the older, experienced engineer refuses to acknowledge the findings.  The last few stories really remind us older engineers to pay close attention to new ideas and never brush them aside.

<<  <  Page 3/3

Partner Zone
Latest Analysis
Samsung's Galaxy line of smartphones used to fare quite well in the repairability department, but last year's flagship S5 model took a tumble, scoring a meh-inducing 5/10. Will the newly redesigned S6 lead us back into star-studded territory, or will we sink further into the depths of a repairability black hole?
Fifteen European research centers have launched EuroCPS to help European companies develop innovative products for the Internet of Things.
Get your Allman Brothers albums ready. The iconic Volkswagen Microbus may be poised for a comeback, and this time it could be electric.
In 2003, the world contained just over 500 million Internet-connected devices. By 2010, this figure had risen to 12.5 billion connected objects, almost six devices per individual with access to the Internet. Now, as we move into 2015, the number of connected 'things' is expected to reach 25 billion, ultimately edging toward 50 billion by the end of the decade.
NASA engineer Brian Trease studied abroad in Japan as a high school student and used to fold fast-food wrappers into cranes using origami techniques he learned in library books. Inspired by this, he began to imagine that origami could be applied to building spacecraft components, particularly solar panels that could one day send solar power from space to be used on earth.
Design News Webinar Series
3/31/2015 11:00 a.m. California / 2:00 p.m. New York
2/25/2015 11:00 a.m. California / 2:00 p.m. New York
12/11/2014 8:00 a.m. California / 11:00 a.m. New York
5/7/2015 11:00 a.m. California / 2:00 p.m. New York
Quick Poll
The Continuing Education Center offers engineers an entirely new way to get the education they need to formulate next-generation solutions.
Apr 20 - 24, Taking the Internet of Things to the Cloud
SEMESTERS: 1  |  2  |  3  |  4  |  5  |  6 |  7

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.
Last Archived Class
Sponsored by Proto Labs
Learn More   |   Login   |   Archived Classes
Twitter Feed
Design News Twitter Feed
Like Us on Facebook

Sponsored Content

Technology Marketplace

Copyright © 2015 UBM Canon, A UBM company, All rights reserved. Privacy Policy | Terms of Service