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.
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.
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.
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.
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.
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.
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".
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.
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"!
This must have been before cellphones with cameras became ubiquitous. I can't even begin to describe how much easier my life has become thanks to these handy data-gathering tools.
That said, I recall having one of these once, except I was the guy on the other end. I kept getting field reports that a piece of my robot software kept crashing the robot into a structural member under specific conditions. I kept going over and over my code, and kept finding that event to be impossible. The kicker was, I didn't know that no one in the field had ever installed the latest revision patch that fixed that problem, and the person responsible for installing that patch had been let go. So the code I was looking at was not what was running in the machine.
Lesson learned: always get the actual running code.
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.