Jump to content

Randomly enable the built-in IXEG failures - LUA script


Tom Stian

Recommended Posts

VREF is the computed airspeed by the FMC (derivates from gross weigh & flaps selected) for the final approach speed you should cross over the runway threshold for safety, maneuverability and landing distance.

 

VREF + corrections is what you need for landing under normal conditions.

 

Corrections:

-Auto-throttle accuracy +5 knots

-Severe icing +5 knots (for avoiding icing formation on non heated parts)

-If winds are present (winds present means >5 knots) then +half knots of the head steady winds + full knots gusts (note is HEAD wind component, not any wind speed, head steady wind +50%, 45 degree 35%, 90 full crossed 0%, subsequent angles interpolation)

 

Rules for corrections:

1. Resulting corrections can not be greater than +20 knots in any case or landing flap placard -5 knots, whichever is lower (so maximum is VREF +20 or lower)

2. If you already had to apply > +5 knots due to icing or winds, you ignore +5 knots for auto-throttle accuracy.

3. Gust correction has to be maintained till touchdown! corrections due to auto-throttle or steady winds or icing bleed off from the threshold.

4. Tail wind conditions. Set vref + 5 knots. Check maximum aircraft tail wind allowed (typically 15 knots of max tail wind present conditions)

Link to comment
Share on other sites

12 hours ago, mmerelles said:

-If winds are present (winds present means >5 knots) then +half knots of the head steady winds + full knots gusts (note is HEAD wind component, not any wind speed, head steady wind +50%, 45 degree 35%, 90 full crossed 0%, subsequent angles interpolation)

[...]

4. Tail wind conditions. Set vref + 5 knots. Check maximum aircraft tail wind allowed (typically 15 knots of max tail wind present conditions)

Hi, thanks for this comprehensive explanation. What I'm still wondering about is why a steady head wind component has to be balanced - normally, a steady head wind should allow for a slower landing ground speed, preserving tires and brakes. Using this correction partly gives away the advantage of a steady head wind. However, it is not needed to avoid dropping below critical air speed... so why is it done? Courtesy for ATC to avoid snailing on final, or...?

Link to comment
Share on other sites

1 hour ago, daemotron said:

Hi, thanks for this comprehensive explanation. What I'm still wondering about is why a steady head wind component has to be balanced - normally, a steady head wind should allow for a slower landing ground speed, preserving tires and brakes. Using this correction partly gives away the advantage of a steady head wind. However, it is not needed to avoid dropping below critical air speed... so why is it done? Courtesy for ATC to avoid snailing on final, or...?

Simply a safety addition. If there is a lot of wind, chances are it may get gusty/turbulent near the ground (buildings,trees,etc.). More speed also enhances controllability, provides more stall margin/better energy reserve for a go-around and lessens WCA.

Jan

  • Upvote 1
Link to comment
Share on other sites

  • 4 weeks later...

Hey,

haven't tried your script yet but thanks in advance for your work. I was just wondering why such a script is necessary. Doesn't the default failure system of X-Plane work with the IXEG B733? I never tried it, but it also has the same features I guess. In any case your script seems to be a plug and play solution which is nice, but I'm a fan of utilizing available options as much as possible :)

Best regards,

Bene

Link to comment
Share on other sites

On 10.8.2017 at 4:16 PM, BaBene said:

Hey,

haven't tried your script yet but thanks in advance for your work. I was just wondering why such a script is necessary. Doesn't the default failure system of X-Plane work with the IXEG B733? I never tried it, but it also has the same features I guess. In any case your script seems to be a plug and play solution which is nice, but I'm a fan of utilizing available options as much as possible :)

Best regards,

Bene

Hello

My script was created for randomly enable the failures that IXEG have made for us (+ some extra failures as engine fire). Check first post for available failures.

The IXEG 737-300 have custom made systems and logics that are not covered by X-Planes failure model. :)

Link to comment
Share on other sites

27 minutes ago, BaBene said:

Yes I did notice that the X-Plane 11 default failure system does not work. Tried your script and works flawlessly, great work!

Good to hear..:)

If you think you get failures to often, change the  MTBF_hours to 20. That will be the default in next update

 

Link to comment
Share on other sites

Studying your script I was wondering if the MTBF actually makes sense there. As far as I can tell you never save the time on the airframe (If I understand it correctly Cycles will always be set to 0 on each new script startup). So if I only do let's say short haul 1h flights, it would be highly unlikely that a failure occurs. That's not what I would expect. Could you clarify this for me? I may just have got it completely wrong, I'm by no means a LUA expert :)

Regards,

Bene

Link to comment
Share on other sites

9 minutes ago, BaBene said:

Studying your script I was wondering if the MTBF actually makes sense there. As far as I can tell you never save the time on the airframe (If I understand it correctly Cycles will always be set to 0 on each new script startup). So if I only do let's say short haul 1h flights, it would be highly unlikely that a failure occurs. That's not what I would expect. Could you clarify this for me? I may just have got it completely wrong, I'm by no means a LUA expert :)

Regards,

Bene

There is no history/logging between flights.. So the MTBF is "resetted" everytime you load the aircraft. 

So the MTBF just say something how often the failure can occur. :)

But maybe some logging between the flights would be something for the next version. Thanks for the idea :)

 

Link to comment
Share on other sites

3 hours ago, BaBene said:

Studying your script I was wondering if the MTBF actually makes sense there. As far as I can tell you never save the time on the airframe (If I understand it correctly Cycles will always be set to 0 on each new script startup). So if I only do let's say short haul 1h flights, it would be highly unlikely that a failure occurs. That's not what I would expect. Could you clarify this for me? I may just have got it completely wrong, I'm by no means a LUA expert :)

You are confusing MTBF and lifetime expectancy.

The former is about random failures of a device while the latter is about how long a device is expected to last. Those two can be very different.

For example given the 2003 "life table" for the US - a 30-year old has a ~0.1% chance to die in that year - this translates to a MTBF of roughly 1000 years, however even the best wear out long before that - their lifetime expectancy is a mere 49 years. :P

So MTBF expresses really just a random chance to fail and thus does not require any life time tracking.

If you were to implement some form of that (e.g tires lasting only X landings), then you'd need indeed some form of air frame state save.

 

In reality, you'd also hope that maintenance is aware of the lifetime expectancy of the various devices and replaces them before that.

So I don't think you would gain much by tracking stuff across flights, unless you want to implement some sort of maintenance simulation, i.e. replace engines after X hours (depending on usage), etc. along with the financial impact to enable some kind of "running an airline" experience.

 

In this simulation MTBF is really just there to give you a better idea of what to expect, i.e. a MTBF of 20h would mean you should expect one failure in 20h of flight (or 5% per hour, or adhering to how it's programmed: 0.0139% per 10s ) regardless of how those 20h are composed. Since it IS random however, you might experience 20 faults in 10 hours or none in 100h.

In reality the MTBFs are much higher of course and vary from system to system as well, while here it's all combined into one.

Edited by mfor
  • Upvote 1
Link to comment
Share on other sites

3 hours ago, BaBene said:

Studying your script I was wondering if the MTBF actually makes sense there. As far as I can tell you never save the time on the airframe (If I understand it correctly Cycles will always be set to 0 on each new script startup). So if I only do let's say short haul 1h flights, it would be highly unlikely that a failure occurs. That's not what I would expect. Could you clarify this for me? I may just have got it completely wrong, I'm by no means a LUA expert :)

Regards,

Bene

After some thinking about logging the cycle between flights its giving no sense. Since each cycle have the equal chance to fail :)

 

Link to comment
Share on other sites

Testing out some new tweaks on the MTBF-code.

This is for now just a test, but I tried to smooth out the MTBF a little.

So what I have done is to make the failures less chance to happend if your flight time is below the MTBF you have set, and equal higher chance when you are above the MTBF.

 

What do you think ? 

The result is this

 

OLD:

ddAMuRe.png

 

NEW:

h6OHUzc.png

 

Edited by Tom Stian
Link to comment
Share on other sites

Well I'd prefer it to be constant to be honest or even an increased chance at the start, as a failure shortly after takeoff is more uhmm.. intense.

Also unless you set the MTBF really low you're not really going to hit the "above MTBF" phase.

So instead I'd suggest some button (or dataref) that you can hit to cause a random failure in the next 5 or 10 minutes or so. That way you do have a way to trigger a fault quickly (if you are bored or want an interesting takeoff/landing) but still be somewhat surprised by it and don't have to lower the MTBF to ridiculous levels.

Link to comment
Share on other sites

22 hours ago, mfor said:

So instead I'd suggest some button (or dataref) that you can hit to cause a random failure in the next 5 or 10 minutes or so. That way you do have a way to trigger a fault quickly (if you are bored or want an interesting takeoff/landing) but still be somewhat surprised by it and don't have to lower the MTBF to ridiculous levels.

Do we need to request a "Red button" from Jan ? :D

peter.jpg

 

Anyway, something like this ?

If you set the service interphone to "ON" you force the MTBF to 5 minutes in this test. I could maybe increase it to 10min.

  • Upvote 1
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...
  • Recently Browsing   0 members

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