X-Virus-Scanned: clean according to Sophos on Logan.com Return-Path: Received: from outbound-mail.vgs.untd.com ([64.136.55.15] verified) by logan.com (CommuniGate Pro SMTP 5.3.4) with SMTP id 4166901 for flyrotary@lancaironline.net; Mon, 15 Mar 2010 19:34:58 -0400 Received-SPF: pass receiver=logan.com; client-ip=64.136.55.15; envelope-from=alwick@juno.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juno.com; s=alpha; t=1268696063; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; l=0; h=Message-ID:From:To:Subject:Date:Content-Type; b=ITjJOJzEyfh94j/pnoVF7uNNQ8RMBEfneBRBOs9/gMLqCISvSc/aax8wuoVWsW8Hs 8ZrHdB72EiENHZuvocWefcWC4X2mHcZQTLkhAW+isb1y9lgvyBXZO03wdiGdX5kRQJ 5MKypFYCVXsBXNLnQJl79w8Y7hmI9HcUubekwTPk= Received: from Penny (c-98-246-117-71.hsd1.or.comcast.net [98.246.117.71]) by smtpout04.vgs.untd.com with SMTP id AABF37S9TANLZ42A for (sender ); Mon, 15 Mar 2010 16:34:09 -0700 (PST) Message-ID: <8A984D2958F14F96BFF11F4112918887@Penny> From: "Al Wick" To: "Rotary motors in aircraft" References: In-Reply-To: Subject: Re: [FlyRotary] Re: Ut-Oh... Date: Mon, 15 Mar 2010 16:34:09 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0101_01CAC45D.565FC500" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18005 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 X-UNTD-BodySize: 10403 X-ContentStamp: 25:12:326908864 X-MAIL-INFO:115ef7daf7ab3a97abda63dbda9acbfa0277bb07ca2e87af077713e313974f872a13fa9e0bee0bee7a8eeeeb7a6eeb7afe2a63d39acafecbda5b9a3a73178b8b6bf3c7938f0b4fee3ea30bebd7d73ba3576f1bb3478e47bf1f5bcb27e7d77b8f671f3e2b6783c343231a3bbadbbfba3bbe7aee8f2e87af077713e31397ce7e5a2a37cfbe1aababd35edfaf27deaacb X-UNTD-OriginStamp: L941HVjjYzDhN3itp//mkP4M6bSURHcInxSsx9Fqki9EWZ4DK6GeQw== X-UNTD-Peer-Info: 10.181.42.34|smtpout04.vgs.untd.com|smtpout04.vgs.untd.com|alwick@juno.com This is a multi-part message in MIME format. ------=_NextPart_000_0101_01CAC45D.565FC500 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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.=20 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.=20 regards -al wick ----- Original Message -----=20 From: Ernest Christley=20 To: Rotary motors in aircraft=20 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,=20 > 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=20 > same "oops" were so common. Think about this. If engine has been=20 > running for more than 5 minutes, only allow small mixture changes.=20 > Never enough to shut down engine. So let's say that 100 will shut = down=20 > engine, then we only allow a change of 20 each minute. Staying with your scenario, 100 will shut down the engine, but it = takes=20 80 to go from climb ROP to leaned for cruise. Your fix would require = 4=20 minutes to effect the change. 4 minutes of constant power changes,=20 requiring constant pitch trim modifications. And if you hit the cold=20 start by accident, you wouldn't see a drastic and immediate power=20 change. You would see a slow decrease, possibly preceded by a slow=20 increase, that would not necessarily tie directly back to the initial=20 control change. Not to belittle your idea for a fix. It was probably an off-the-cuff=20 solution that you haven't spent lots of hours thinking about=20 specifically. I'm just trying to highlight the point that "providing = assistance" in software quite often means introducing a PITA.=20 The design pattern is that powerful controls are presented to the=20 operator of the system in order to supply necessary functionality. = This=20 creates the delimma of a necessary control opening the system to = severe=20 problem scenarios in the case of user error. There are many ways to=20 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=20 using the EC2 in warmer climates. -One solution is more user training.=20 -One solution is ergonomic enhancements, in this case moving the = switch=20 close to the start button, which are then both moved physically to an=20 area remote from other switches. -One solution is a design that gets around the need for the control. =20 The Megasquirt uses a temperature sensor to enrichen the mixture on a=20 cold morning. (I'll let you know how that works out for me after I = get=20 my system running.) -IMHO, the worst of all solutions is a software fix that presents a=20 control that behaves differently under varying conditions. The = operator=20 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=20 data to correlate with would have to be an abstract number for a=20 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=20 from existing sensors? I would then look to ergonomically protect the = switch. Remoting the location. Installing a toggle protector. My = last=20 resort would be increased operator training. -- Homepage: http://www.flyrotary.com/ Archive and UnSub: = http://mail.lancaironline.net:81/lists/flyrotary/List.html ------=_NextPart_000_0101_01CAC45D.565FC500 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Excellent critique Ernest. Good = positive=20 brainstorming for alternate solutions. As you thought, my suggestion for = allowing mixture change of 20 per minute was just intended as rough = example of=20 concept.
 
I like your summary, things you plan on = doing. I'm=20 eager for a solution that's far reaching. One that automatically affects = every=20 Rotary. I think this group is on the verge of blowing thru the = historical=20 problems, achieving some genuine reliability. Good sharing, good = science,=20 testing. Based on incidents, I really think ECU changes in response = to past failures is a key.
 
regards
 
-al wick
 
 
----- Original Message -----
From:=20 Ernest=20 Christley
Sent: Monday, March 15, 2010 = 12:13=20 PM
Subject: [FlyRotary] Re: = Ut-Oh...

Al Wick wrote:
> As soon as one of these ECU = suppliers=20 adds the "Are you sure?" logic,
> then all of these failures = disappear.=20 Pretty simple logic statement.
> Actually, there are a whole = bunch of=20 ways this can be handled. I had
> to do this type of = programming with=20 industrial plc's because these
> same "oops" were so common. = Think=20 about this. If engine has been
> running for more than 5 = minutes, only=20 allow small mixture changes.
> Never enough to shut down = engine. So=20 let's say that 100 will shut down
> engine, then we only allow = a change=20 of 20 each minute.
Staying with your scenario, 100 will shut down = the=20 engine, but it takes
80 to go from climb ROP to leaned for = cruise. =20 Your fix would require 4
minutes to effect the change.  4 = minutes of=20 constant power changes,
requiring constant pitch trim = modifications. =20 And if you hit the cold
start by accident, you wouldn't see a = drastic and=20 immediate power
change.  You would see a slow decrease, = possibly=20 preceded by a slow
increase, that would not necessarily tie = directly back=20 to the initial
control change.

Not to belittle your idea = for a=20 fix.  It was probably an off-the-cuff
solution that you = haven't spent=20 lots of hours thinking about
specifically.   I'm just = trying to=20 highlight the point that "providing
assistance" in software quite = often=20 means introducing a PITA.

The design pattern is that powerful = controls=20 are presented to the
operator of the system in order to supply = necessary=20 functionality.  This
creates the delimma of a necessary = control=20 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=20 necessary in the first place.  This solution does apply to those=20
using the EC2 in warmer climates.
-One solution is more user = training.=20
-One solution is ergonomic enhancements, in this case moving the = switch=20
close to the start button, which are then both moved physically to = an=20
area remote from other switches.
-One solution is a design that = gets=20 around the need for the control. 
The Megasquirt uses a = temperature=20 sensor to enrichen the mixture on a
cold morning.  (I'll let = you know=20 how that works out for me after I get
my system = running.)
-IMHO, the=20 worst of all solutions is a software fix that presents a
control = that=20 behaves differently under varying conditions.  The operator =
has one=20 control that he must correlate with the current situation when=20
using.  This situation is would be made worse in this case, = since the=20
data to correlate with would have to be an abstract number for a=20
temperature sensor.

I would first look to eliminate = exposing the=20 control to the operator. 
Is it necessary?  Can I get = the=20 information I need to turn on cold start
from existing = sensors?  I=20 would then look to ergonomically protect the
switch.  = Remoting the=20 location.  Installing a toggle protector.  My last =
resort would=20 be increased operator training.


--
Homepage:  http://www.flyrotary.com/
Archi= ve and=20 UnSub:   http:= //mail.lancaironline.net:81/lists/flyrotary/List.html
------=_NextPart_000_0101_01CAC45D.565FC500--