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.
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".
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.
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.
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.
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 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.
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.
Robots that walk have come a long way from simple barebones walking machines or pairs of legs without an upper body and head. Much of the research these days focuses on making more humanoid robots. But they are not all created equal.
The IEEE Computer Society has named the top 10 trends for 2014. You can expect the convergence of cloud computing and mobile devices, advances in health care data and devices, as well as privacy issues in social media to make the headlines. And 3D printing came out of nowhere to make a big splash.
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 discussion will examine what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.