Jump to content

Subsequent Start EGT behavior inconsistent with first start and Condition Lever movement when switches are actuated


Recommended Posts

Thanks for bringing the MU2 up to date! I really like the improvements. I have a couple areas of note:
1) After engine shutdown any subsequent ignition during start results in EGTs going immediately up to 700+C in less than 1 second while fuel flow behavior is consistent between starts, is this expected? If the engine necessitates a motor to reduce EGT would it be possible to implement an egt behavior that would indicate the engine is too hot to start? Additionally the subsequent restarts between engine 1 and 2 are not consistent. Engine 1 will have a max EGT of ~950C while engine 2 will remain at or below ~750C (video Below) EDIT: Additionally it appears that the EGT spike preceeds the fuel flow which thermodynamically doesnt seems to make much sense unless the sensors for the EGT are more responsive than those measuring fuel flow.

2) When pressing the unfeather buttons, the state of the condition levers change (Video below) the same occurs when using the engine stop switches. The unfeather switches cause the model animation to indicate movement aft, the stop switches indicate movement forward. I noticed this because I can set the hardware axis to bounce between two animation key frames which causes slight jittering in the animation and a constant update.

Video order: Engine Start Video, control axis video

 

Edited by CaptCrash
Link to comment
Share on other sites

 

This is a quick response (at Starbucks)  will look at videos more in depth later and reponse below this one.

Quote

1) After engine shutdown any subsequent ignition during start results in EGTs going immediately up to 700+C in less than 1 second while fuel flow behavior is consistent between starts, is this expected?

That does not sound normal for sure and will take a look.  Certainly the start behavior should be reasonably similar each time the engine starts.  In reality, EGT sensors probably would not reflect residual heat to that kind of a level from a recent shutdown simply due to the dynamics of the process.

Quote

If the engine necessitates a motor to reduce EGT would it be possible to implement an egt behavior that would indicate the engine is too hot to start? Additionally the subsequent restarts between engine 1 and 2 are not consistent. Engine 1 will have a max EGT of ~950C while engine 2 will remain at or below ~750C (video Below) EDIT: Additionally it appears that the EGT spike preceeds the fuel flow which thermodynamically doesnt seems to make much sense unless the sensors for the EGT are more responsive than those measuring fuel flow.

The 950ºc spike ceratainly is worth a look on my part.  There is certainly room for improvment in the start/shutdown process.  My only long-term recourse to get time-dependent thermodynamic behaviors is to fully override the engine model and this is absolutely on the roadmap but a sizeable job.  Right now, I 'override' then 'relenquish' control of the engine in various regimes and this does create discontinuities that are difficult to overcome with this hybrid control method.  Its not ideal I agree but I will address it in the future.  I'll look at your videos more in depth though for "obvious bugs" as those could exist....because certainly the EGT spike should not precede the fuel flow.

Quote

2) When pressing the unfeather buttons, the state of the condition levers change (Video below) the same occurs when using the engine stop switches. The unfeather switches cause the model animation to indicate movement aft, the stop switches indicate movement forward. I noticed this because I can set the hardware axis to bounce between two animation key frames which causes slight jittering in the animation and a constant update

This is a known bug and actually the last one I was working on before release.   I just could not get it to work satisfactorily without potentially breaking things and at the 11th hour, that's not a wise idea.  THAT being said...neither did I find a solution and as of now, believe that full override is the way forward.

What I expect...is that over the next several weeks, the glaring bugs will diminish, we'll get through a patch or two.  I'll do the GTN variant in short order and then as I begin to port to XP12, I'll start looking at more robust overrides of X-Plane controls.  Once that happens, I expect the behaviors of the engine in start/stop to increase in accuracy dramatically and then as I get the failures/GUI developed over time, I'll start looking at the time-dependency and hot start conditions etc.

 

Edited by tkyler
Link to comment
Share on other sites

adding a bit more...cause that above was rapid fire from a Starbucks.

The "big problem" for us is that several Plane-maker behaviors like EGT are governed by a single variable in X-Plane, from which X-Plane derives the EGT over certain ranges of operation...  and when we change this variable to affect one engine, then it affects the other engine in an adverse way and cause the opposite engine state to change. The only way to truly get independent control is a full override, which means discarding X-Plane's engine model almost entirely and that is a sizeable job.  Honeywell isn't exactly mailing me all their performance data...but again, it is on the roadmap.  I'm particularly sensitive to the start/shutdown procedures and really want to get these right.

Edited by tkyler
Link to comment
Share on other sites

Thanks for the quick response! I fully understand and empathize with your frustrations with the stock engine model. Having done some detailed mapping of the system for my own project I quickly came to the realization a that the stock engine model is functionally a single state function that can only be effectively tuned for takeoff or cruise performance in the case of the turbine part of the model. I look forward to seeing the updates!

Link to comment
Share on other sites

If Austin implements "per engine" max values like EGT for XP12 and such, then that would improve things greatly for devs not attempting full overrides, indeed I could probably make the Moo quite a bit more accurate if so; however, I'll probably still head down the full override route for the things I can't foresee.

Link to comment
Share on other sites

With the turbine engines especially, they model of N2(throttle) -> N1 -> FF / EGT / oil press / Thrust, is challenging to work around because of the fixed N1 vs N2 relationship being insensitive to ANY atmospheric conditions including air density so I found I had to tune for takeoff or cruise but couldn't do both.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...