Tom Stian

Randomly enable the built-in IXEG failures - LUA script

61 posts in this topic

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)

0

Share this post


Link to post
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...?

0

Share this post


Link to post
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

1

Share this post


Link to post
Share on other sites

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

0

Share this post


Link to post
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. :)

0

Share this post


Link to post
Share on other sites

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

0

Share this post


Link to post
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

 

0

Share this post


Link to post
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

0

Share this post


Link to post
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 :)

 

0

Share this post


Link to post
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
1

Share this post


Link to post
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 :)

 

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.