HOME  |  NEWS  |  BLOGS  |  MESSAGES  |  FEATURES  |  VIDEOS  |  WEBINARS  |  INDUSTRIES  |  FOCUS ON FUNDAMENTALS
  |  REGISTER  |  LOGIN  |  HELP
Blogs
Sherlock Ohms

Can You Diagnose This Engineering Mystery?

NO RATINGS
View Comments: Newest First|Oldest First|Threaded View
<<  <  Page 3/3
OLD_CURMUDGEON
User Rank
Platinum
MY two cents ...
OLD_CURMUDGEON   10/11/2013 11:12:18 AM
NO RATINGS
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"!

ADIOS!

GTOlover
User Rank
Platinum
Re: Seeing is (most of the time) believing
GTOlover   10/11/2013 10:55:03 AM
NO RATINGS
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.

Hank-4
User Rank
Silver
Seeing is (most of the time) believing
Hank-4   10/11/2013 10:28:55 AM
NO RATINGS
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".

 

 

 

greenewr
User Rank
Silver
It's the 'Over the wall' syndrome
greenewr   10/11/2013 10:11:51 AM
NO RATINGS
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.

Noswad
User Rank
Gold
Who knows, not even Bo
Noswad   10/11/2013 9:39:50 AM
NO RATINGS
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
Gold
Logic, or assumptions?
Ken E.   10/11/2013 9:19:46 AM
NO RATINGS

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.

GlennA
User Rank
Gold
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.

armorris
User Rank
Platinum
Been there, had that done to me
armorris   10/10/2013 9:50:25 AM
NO RATINGS
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.

tekochip
User Rank
Platinum
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
More Blogs from Sherlock Ohms
Sherlock Ohms highlights stories told by engineers who have used their deductive reasoning and technical prowess to troubleshoot and solve the most perplexing engineering mysteries.
Sherlock Ohms highlights stories told by engineers who have used their deductive reasoning and technical prowess to troubleshoot and solve the most perplexing engineering mysteries.
Sherlock Ohms highlights stories told by engineers who have used their deductive reasoning and technical prowess to troubleshoot and solve the most perplexing engineering mysteries.
Sherlock Ohms highlights stories told by engineers who have used their deductive reasoning and technical prowess to troubleshoot and solve the most perplexing engineering mysteries.
Sherlock Ohms highlights stories told by engineers who have used their deductive reasoning and technical prowess to troubleshoot and solve the most perplexing engineering mysteries.
Design News Webinar Series
11/19/2014 11:00 a.m. California / 2:00 p.m. New York
11/6/2014 11:00 a.m. California / 2:00 p.m. New York
10/7/2014 8:00 a.m. California / 11:00 a.m. New York
12/11/2014 8:00 a.m. California / 11:00 a.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.
Dec 1 - 5, An Introduction to Embedded Software Architecture and Design
SEMESTERS: 1  |  2  |  3  |  4  |  5  |  6


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 Littelfuse
Learn More   |   Login   |   Archived Classes
Twitter Feed
Design News Twitter Feed
Like Us on Facebook

Sponsored Content

Technology Marketplace

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