|
When we are pursuing a problem like Johns, we are eager to find the
cause. It's a great relief when we do. We say "Eureka!". We did it! We did
it! This sense of relief is a root cause for failure. We are so eager to get the
problem off our back, that we don't take the next step....
Yes, I know you firmly believe this connector was the problem. But if you
can force yourself to pretend it WASN'T, then you can do this:
Is the cause logical? Like is that really the wire that causes that effect?
If I remove that wire, does it have the same effect? What if I have two things
causing the same thing? By pretending that really wasn't the cause, then you
will do some more testing, looking around. Looking for similar connector issues,
stuff like that.
Now I have to admit, this really does sound like he found the cause. But
I've seen this scenario so often. So you use the disciplines I suggest to reduce
your risk. Logical cause? Can I make it recur?
Repeat after me: "Al Wick is an idiot". "Al will jump to conclusions". If
you believe that, then you start finding ways to prove your theory with
facts instead of just accepting your first conclusion. My best
asset is that I know I'm an idiot.
Yeah, yeah, I know, you guys already knew I was.
We had a perfect example of this on Cozy list couple weeks ago. Subaru
engine slipped 2 teeth on timing belt. Would no longer start. Keith talked to
expert and the guy said:"You know, the engine normally is never rotated
backwards. But you've been pushing your new prop backwards recently (installing
new prop). I think you relaxed the belt tensioner when going backwards and
caused it to skip tooth." So Keith said" Yes, all of that's true. That has to be
it."
But then one of the guys looked into it, guess what? The direction the belt
slipped is the opposite of that theory. That could not have caused it.
The lesson? Prove all aspects of the theory are logical. Prove that all the
various facts support the theory. Find a way to convert your theory
to facts!
Oh, by the way, if you look at my analysis of my engine risks....you will
notice that timing belt is the highest risk item on this engine. So we have
exposed another root cause for his problem. He didn't focus on the leading cause
for all engine failures. When we reviewed some facts he had, we found conclusive
evidence he had loose belt from day one! It was installed wrong.
Regarding CAS risk. It's not just crank angle sensor that is the risk item.
Going to redundancy with the CAS will dramatically reduce risk of all ECM
causes. Like this connector risk. I'm not always proponent of redundancy, but
with my limited info on this item, I SUSPECT it's significant, positive
step.
-al wick
Artificial intelligence in cockpit, Cozy IV powered by
stock Subaru 2.5
N9032U 200+ hours on engine/airframe from Portland,
Oregon
Prop construct, Subaru install, Risk assessment, Glass panel design
info:
http://www.maddyhome.com/canardpages/pages/alwick/index.html
On Sun, 5 Jun 2005 21:44:00 -0400 "Tracy Crook" < lors01@msn.com> writes:
Ahh.. Music to my ears John : )
And this brings up the subject of risk (rotary & otherwise)
that Al W. (and every other builder I know) is concerned with. I agree
with Al W. that getting to the major causes of failures is a (hell, THE) key
issue. That is why I have not spent much time on the crank angle sensor
single point failure question. I have never seen or heard of a confirmed
Mazda 13B CAS failure. Can it happen? Of course. I am in the
process of developing a dual CAS for the Renesis CAS but it is not a 'front
burner' project.
I'm reading between the lines of Al's posts but it seems that he
is emphasizing the importance of leaving the engine as un-touched as
possible. I once wrote an article for Light Plane World (EAA's
ultralight magazine back in the late 80's) and advocated the same thing after
noting that many Rotax failures occurred soon after the owner opened up
the engine for maintenance. Decarboning the piston ring grooves was
important but many builders were causing more problems than they fixed when
they went inside so I recommended some products and procedures that would do
the job without opening the engine.
That was the basic gist anyway but I eventually decided
this was not a reasonable approach for builders who planned on installing an
alternative engine in 200 mph category airplanes. There were simply far
too many areas where things could go wrong in this process. The root
cause of the problems had to be identified. One of the names I
gave to the cause is a term I recently used on this list - Shopcraft (or
lack of). This referred to the ability to identify the quality or
suitability of virtually everything that goes into the plane. Yes, I
know this is a generality of the highest order but if we are to get to
the root cause of failures in the field of alternative aircraft engines, this
level of abstraction is required.
It has been suggested that a collection of 'best practices' might
be a solution. This may help but it is not a solution.
There is an unlimited number of potential problem areas so a list of them
could never be compiled. So, how do you learn to recognize what is
or is not a 'good thing'? I'm getting so frustrated just trying to
describe the problem that there may not be a solution, at least not one that
can be spelled out in something like an email
message. Damn, now I can't even criticize Al W. for
not spelling it out.
The best I can do for now is to emphasize two things. Pay
attention to every detail and admit to yourself when you don't have the
ability to execute something well. Another version of these
rules was given to me long ago:
1. Rules are for those who are not smart enough to make up
their own. (Author unknown)
2. A man's got to know his own limitations. (Dirty
Harry)
3. Always follow BOTH rules 1 & 2.
Small details like the problem of soldering thermocouple wire to
a connector that Al Gietzen mentioned can be critically important.
He was able to recognize the problem (he made a lousy solder joint) and devise
a solution (acid flux) even though it violated one of the cardinal rules of
electrical wiring. He recognized that too and took the steps necessary
to achieve satisfactory results (knowing when to make up his own
rules).
Out of time, I'll stop blathering now.
Tracy
Subject: [FlyRotary] EC2 problems - solved
Tracy and
others.
Following more than 12 months of battling with EC2 issues
I'm pretty sure it's Eureka day!
After
rewiring and testing for almost 4 weeks I plugged the EC2 in last night, and
got exactly the same symptoms as before. NOP flashing indicating no
communication. I took the EC2 to Buly's plane and tried it in his
installation. Same NOP, so I was thinking I'd fried it again. Before sending
it back yet again I decided to install it my plane one more time and see if
there was a spark.
To my
amazement it worked. No NOP, and I could bring up the EC2 data. The only
thing that changed overnight was that I moved the cable to unplug it. I
climbed in the back and found that I could make the NOP flash, or stop
flashing, by moving the cable. I haven't taken the connector apart yet,
but I'm expecting to find a broken wire inside the insulation, probably near
a solder joint at the pin. Whenever I bent the connector outward for
testing it made contact. When I bent it back to plug it in, contact was
lost.
Bingo!
John
Just guessing, but maybe the new EC2
can't communicate with a pre-autotune EM2 like Buly's.
???
|