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.
post vy much lie case of the "Jm Moore"syndrome, which is that "if I think it is that way, then it IS that way", which often leads to incorrect conclusions. I have had sevice techs describe things to me over the phone and on some occasions my respons is "that can't happen", but since it has been observed, the clearly there is problem. The assertion tht it can't happen tells the tech tht I believe they have found at least part of the problem, and the statement that there is a problem verifies that we now need to understand why the thing happened. This has been as simple as a damaged limit switch bracket to as complex as a hydraulic control valve that was sometimes sticking because it was full of dir, on a stamping press that would sometimes do a second stroke after the two-hand buttons were released. Just because something can't happen des not mean that it won't happen.
But the best way to diagnose a problem is to be able to understand how the process is supposed to function, and then observe how itis actuallyfunctioning, and then figure out why the two are different. That method is fairly different from thesymptom-look-up-table method of service diagnostics, which can be useful for service people wo have no cncept of what the process should be.
William, thanks for that very clear and thorough description of what it takes to solve problems like this one. It's a good map, actually, for non-engineering problem-solving, as well. There has to be an agreement about what's happening; i.e., that there is a problem. There has to be knowledge of the way something is supposed to work, and observation of how it actually is working, and analysis of why the difference. This seems like such an elementary map of how to proceed, so elementary, yet I find it escapes many people.
Ann, yes, it is quite obvious to both you and me, but as you say, it is hidden from alot of people. Of course I have the advantage of having done a whole lot ofproblem solving as a regular portion of my employment. That winds up being quite an advantage. Also, finding out what is wrong with a piece of equipment that one has designed ten years earlier still gives one a real advantage.
In general, getting enough information tounderstand how a system should be working, prior to starting to even lookat it, is a big benefit. Howwould one know that something was wrong unless one knew what it was like when it was right.
I guess I've done more problem solving than I realized, William, since much of this seems obvious or elementary. Including as a part of my employment. It's been mostly at a very small level compared to what you do, but the principles are the same.
Ann, it has been obvious to me that you are in the problem solving mode much of the time. That happens a lot to engineers, and sometimes it drives others to distraction, or worse. We look at something and usually see some way, which we would consider obvious, to make it better. Of course it is always easier to see how to improve a design than it is to create that design, and even easier when it is somebody else's design.
And trouble shooting is an extension of that, it seems to me. It almost becomes a "first nature" thing, always considering how things are working and how they should be working. Great for when one is asked to fix something, but not quite a s great when others don't want to hear about what needs to be fixed.
On a totally different subject, I finally had a chance to listen to a huge wind turbine in operation. Actually, I had the chance to listen for it, since I was not able to percieve any sound at all, from about a hundred yards, which is where the "Keep Out" sign was placed. None of my group heard anything, except for one musical person who thought that they might be hearing a slight sound as each blade passed the support structure. In short, it was no louder than a quiet library would be if all the rules were in full force.
Thanks William, I think that's a compliment of sorts. Yes, I tend to be very analytical and think in terms of "problem solving" much, maybe most, of the time. Usually I don 't think of it as such, but more often as finding or fixing things. Like in shopping, looking online for tall sizes (not at all easy), or for an obscure book. Work-related is more like where's the latest info on new robotic designs, where are good photos for this news item, or how can I crowbar information out of PR people/sources for this press release (harder than you might think). Both of these types of seek-and-find missions require similar skills and processes. During all this, I often think "why is this so hard to find"? or "why is this system so hard to use?" or "it would work so much better if you put XYZ on this web page instead of the next web page" or the like. I nearly always see ways to make things work better. Of course, that doesn't mean that making those changes will be feasible.
So you finally found wind turbines to listen to! Thanks for reporting back to us. 100 yards is a good distance. However, from recent experience with noisy neighbors, one of them 500 yards away and up a hill, and related research on sound proofing techniques I've learned a lot about how "sound travels". Actually, it's how "sounds travel," because different sounds travel in different ways through the air or the ground, which differs yet more depending on relative elevations between Point A and Point B, and objects in between. It's actually quite complex. My point is, people farther away than you were could easily be getting different sounds, especially those low-frequency ones that drive some of us nuts, and which others of us apparently can't hear. I find it interesting that the "musical person" noticed something. I'm also musical, and I wonder how much that simply means I notice sounds more, or notice differences in them more.
Good points Ann. What is definite is that whatever the noise is, it is not a forground noise like a chainsaw or diesel engine, but something far more subtle, if it is there at all. Of course, there are also folks who get annoyed at the sound of the hard drive in my Dell notebook computer. So it seems that noise must be in the ear of the beholder, or something like that.
Thanks, William. The fact that it's a "background" noise means it will be more obvious at night when other sounds masking it during the day have disappeared. This is especially true in the country, where most turbines are located. If it's also low-frequency, that magnifies the problem, since those travel through the ground and are much harder to block from entry into one's house (and bedroom) than high frequency sounds. Here's a report on nighttime sounds driving people nuts in many places. http://www.nbcnews.com/science/mysterious-hum-driving-people-crazy-around-world-6C10760872 Note the low percentage (2) of people noticing these sounds. I'd probably be one of them. Also note where the problem occurs most and why (rural and suburban vs urban). Also the age group, probably because older people are lighter sleepers. So yes, it's in the ear of the hearer. But that doesn't diminish the distress. I often wish I didn't hear this stuff.
Ken E; With apologies to Rob Spiegel, my original intent was that when the mechanical adjustments are found to be correct, the next step may be to check the sequencing / programming of the machine. I agree that I did not provide enough information for a reader to diagnose the problem.
taimoortariq; The engineer had decided the problem was a mechanical adjustment, and was not interesrted in any troubleshooting that I had done - he did not want to be confused by the facts. As a 'senior' engineer, his job was to give me instructions, not to listen to what I had found.
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.
The problem is the pressure cylinder extending during start up. Searching/watching vids on youtube for Biesse edge-banding machines to grasp how they work provided some ideas. The description mentions two cylinders but does not clearly describe their individual functions. But, 'cylinders' implies air pressure. The videos show that during operation, the pressure roller moves out prior to the wood edge arriving at the roller. As the wood contacts the roller, it pushes the roll back and that is the 'pressure'. But, the wood clamped to a track traveling a straight path, Glenn mentions a cutting wheel to trim the edge. This sets the depth of the edge of the wood. The pressure wheel has to be depth adjusted for the thickness of the veneer/edging material. If the rotational axis of the pressure roller extends past the surface of the edging material then the roller will 'catch' the material cause problems. The pressure roller is a fixed radius; geometry defines the how much farther the pressure roller can extend pas the surface of the edging material and 'ride' up over the leading edge of the material onto the surface creating pressure. So, how should the depth be set? With the pressure roller retracted, the depth slide is extended and set such that the roller is on the edging material. Next, the depth is fixed using spacers; retraction of the depth slide to lock the spacers pulls the pressure roller slightly away from the edging material. The design would take this distance into account. Now, when the pressure roller is extended, it is a known distance past the surface of edging and can ride over the leading edge onto the surface, pressing the edging into the wood with some leeway for variations in edging material thickness.
So, what is the problem? Retracting the depth slide against the spacer(s) only makes sense if the retraction remains during operation. The first problem appears to be in the description: The paragraph four contains descriptions of what is supposed to happen and what is happening. This makes it hard to separate what is supposed to occur from the problem. The machine's problem is that during depth setting the pressure roller was not supposed to extend. The pressure roller was only supposed to extend during production.
Why is the roller extending during depth-setting instead of staying retracted? I dunno know. But, likely this was Glenn's first or earlier jobs where he was not familiar with the machine's normal operation AND the senior engineer blew off Glenn's description because they (senior) never heard of the problem and Glenn is unfamiliar with the equipment and therefore doesn't know what he (Glenn) is talking about.
RBedell; That is a good description of the machine function. The root cause of the roller being damaged, in my opinion, was that the entire assembly was being advanced during initialization, along with the depth-setting cylinder, instead of just the depth-setting cylinder. I had recently been re-assigned to working on edge-banders. The senior engineer had given me instructions to adjust the machine. After I had checked the adjustment, and found it was correct, I then observed the machine functioning to see if I could find the cause of the problem. I then told the Italian engineer that the adjustment was correct, and the problem was in the machine programming (software). And some omitted information was that I had previous experiences with Italian engineers telling me "You don't understand" when I found problems that they did not like.
I was recently called in to determine why a machine wouldn't start up. The display indicated the oil reserve was low so the plant engineer had re-filled the reservoir but still no start-up. I took off the reservoir controls cover and manually blocked the low level switch so it wouldn't trip. Same problem. So I opened up the electrical box and found a common variable frequency motor controller. We started looking at the drive train and, sure enough, there it was. A set screw on one of the belt drive gears had loosened and the steel link belt it drove had drifted 1/16" to the side and caught on some hardware. The VFD was doing it's job and signaling an overload on startup (insteat of self-destructing the system like an old contactor-based control would have done). The display was reading "oL" which they took to mean "oil" when it meant the obvious ("OL"). Ten minutes later I was out of the plant and production was back to 100%.
Festo's BionicKangaroo combines pneumatic and electrical drive technology, plus very precise controls and condition monitoring. Like a real kangaroo, the BionicKangaroo robot harvests the kinetic energy of each takeoff and immediately uses it to power the next jump.
Design News and Digi-Key presents: Creating & Testing Your First RTOS Application Using MQX, a crash course that will look at defining a project, selecting a target processor, blocking code, defining tasks, completing code, and debugging.
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.