|
Excellent critique Ernest. Good positive
brainstorming for alternate solutions. As you thought, my suggestion for
allowing mixture change of 20 per minute was just intended as rough example of
concept.
I like your summary, things you plan on doing. I'm
eager for a solution that's far reaching. One that automatically affects every
Rotary. I think this group is on the verge of blowing thru the historical
problems, achieving some genuine reliability. Good sharing, good science,
testing. Based on incidents, I really think ECU changes in response
to past failures is a key.
regards
-al wick
----- Original Message -----
Sent: Monday, March 15, 2010 12:13
PM
Subject: [FlyRotary] Re: Ut-Oh...
Al Wick wrote:
> As soon as one of these ECU suppliers
adds the "Are you sure?" logic,
> then all of these failures disappear.
Pretty simple logic statement.
> Actually, there are a whole bunch of
ways this can be handled. I had
> to do this type of programming with
industrial plc's because these
> same "oops" were so common. Think
about this. If engine has been
> running for more than 5 minutes, only
allow small mixture changes.
> Never enough to shut down engine. So
let's say that 100 will shut down
> engine, then we only allow a change
of 20 each minute.
Staying with your scenario, 100 will shut down the
engine, but it takes
80 to go from climb ROP to leaned for cruise.
Your fix would require 4
minutes to effect the change. 4 minutes of
constant power changes,
requiring constant pitch trim modifications.
And if you hit the cold
start by accident, you wouldn't see a drastic and
immediate power
change. You would see a slow decrease, possibly
preceded by a slow
increase, that would not necessarily tie directly back
to the initial
control change.
Not to belittle your idea for a
fix. It was probably an off-the-cuff
solution that you haven't spent
lots of hours thinking about
specifically. I'm just trying to
highlight the point that "providing
assistance" in software quite often
means introducing a PITA.
The design pattern is that powerful controls
are presented to the
operator of the system in order to supply necessary
functionality. This
creates the delimma of a necessary control
opening the system to severe
problem scenarios in the case of user
error. There are many ways to
break the delimma.
-One
solution is to remove the control, which means the control wasn't
really
necessary in the first place. This solution does apply to those
using the EC2 in warmer climates.
-One solution is more user training.
-One solution is ergonomic enhancements, in this case moving the switch
close to the start button, which are then both moved physically to an
area remote from other switches.
-One solution is a design that gets
around the need for the control.
The Megasquirt uses a temperature
sensor to enrichen the mixture on a
cold morning. (I'll let you know
how that works out for me after I get
my system running.)
-IMHO, the
worst of all solutions is a software fix that presents a
control that
behaves differently under varying conditions. The operator
has one
control that he must correlate with the current situation when
using. This situation is would be made worse in this case, since the
data to correlate with would have to be an abstract number for a
temperature sensor.
I would first look to eliminate exposing the
control to the operator.
Is it necessary? Can I get the
information I need to turn on cold start
from existing sensors? I
would then look to ergonomically protect the
switch. Remoting the
location. Installing a toggle protector. My last
resort would
be increased operator training.
--
Homepage: http://www.flyrotary.com/
Archive and
UnSub: http://mail.lancaironline.net:81/lists/flyrotary/List.html
|