Jump to content

Randomly enable the built-in IXEG failures - LUA script


Tom Stian

Recommended Posts

Just now, Cosmopilot said:

Well, I was lucky (or maxbe not),


IXEG Failure triggered: --------------------------
IXEG Failure triggered: Time: 14:55:23 - 31 May 2017
IXEG Failure triggered: Failure happend after: 12 minutes
IXEG Failure triggered: Failed System: EDP B FAST LEAK
IXEG Failure triggered: Failures left: 1
IXEG Failure triggered: --------------------------
IXEG Failure triggered: --------------------------
IXEG Failure triggered: --------------------------
IXEG Failure triggered: Time: 15:46:27 - 31 May 2017
IXEG Failure triggered: Failure happend after: 63 minutes
IXEG Failure triggered: Failed System: ELECTRIC HYD PUMP B
IXEG Failure triggered: Failures left: 0
IXEG Failure triggered: --------------------------
IXEG Failure triggered: --------------------------

:huh:

Holly crap. I think I never had a double failure :D

 

Link to comment
Share on other sites

how do you deal with the "AC/DC eletronic"fails, once AC eletronic 1 fails during my flight.so  a lot of instruments were powered off.shown as the picture,no lights on the transponder pannel(so i have no idea whether it was still work). PCI1.png

And I look for help from my QRH,but nothing find from it,no checklist about eletronic items.

so i want to know how do you deal with the eletronic fails?

many thanks.

Link to comment
Share on other sites

You can switch the transponder to feed off of Bus #2 using the 1-2 switch at the bottom. Other than that I don't think you can do much about it in that case.

Also I'm not sure what exactly fails with the "AC Electronic 1" entry. Tried consulting this schematic from http://www.b737.org.uk/ but there are some issues I couldn't explain.

schemeelectxt.gif

This failure seems to affect the "No1 EL. 115v" box in the lower left, as GWPS and the Captain's altimeter failed with that "AC Eletronic 1" failure. 

Auto-throttle however seemed functional and instead the box on the FO's side went dark, the yaw damper tripped and the No1 Mach warning test failed.

This would indicate a problem in "No1 Elec DC" but from the schematics I can't really tell why those two should be related and whether this a is problem with the failure modeling, the schematic or my understanding of those things ;)

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

@Tom Stian Thank you for providing this script and a question/suggestion if I may:

Have you considered using an MTBF number instead of an arbitrary FailFactor, that get's checked twice (against 1..2000 and 1..100) giving it some odd squared characteristic up to a value of 100?

local mtbf_hours = 2.5
local test = math.random (1 , mtbf_hours*360)
if test == 1 then ...

I think this should give you the failure chance for a MBTF of mtbf_hours if called every 10 seconds, which would make it easier to estimate what amount of failures to expect.

 

Edited by mfor
Link to comment
Share on other sites

That's why they're called pseudo-random numbers ;)

However calling the function twice (as the script does now) doesn't improve the "randomness".

As long as the function roughly follows the expected distribution it doesn't really matter in this case though, as we're not building a crypto application where true randomness is essential, but just a "random failure" feature where inspiring the feeling of randomness in a human observer is sufficient.

 

Edit: IIRC rand() in php is/was notoriously bad, which is why mt_rand() was introduced and made an alias for rand in php 7.1.

Also Windows actually offers CryptGenRandom if you need a fairly good random generator, which would be overkill in this case though.

Edited by mfor
Link to comment
Share on other sites

Im no hardcore programmer. Last time I did "serious" programming was with Turbo Pascal 7.0 ;)

When I made this script I had some issues with getting the failures in the same order every time. So this is what I came up with.

But your right, my random rutine can be much better. And a good MTBF would be awesome.
I will try out your example for the MTBF and see if I can get it to work in my script.

Link to comment
Share on other sites

 

36 minutes ago, Tom Stian said:

Im no hardcore programmer. Last time I did "serious" programming was with Turbo Pascal 7.0 ;)

Those were the days :)

Getting the same failures over and over again would be a sign of using the same random seed for each run (which would produce the same number sequence every time).

Edited by mfor
Link to comment
Share on other sites

@mfor

I did test out your MTBF rutine and got this result

 

CH4gGDI.png

 

The code I tested with was this

local mtbf_hours = 2.5
local counter_WIZVAR = 1

math.randomseed( os.time() )

function failedMTBF()

	test_WIZVAR = math.random (1 , mtbf_hours*360)

	if test_WIZVAR == 1  then 
	print ("Failure after " .. math.floor (( counter_WIZVAR * 10 ) / 60 ) .. " min" .. ""  )
	LogWrite = io.open("MTBF.txt", "a")
	LogWrite:write( math.floor((counter_WIZVAR * 10) / 60) , "\n" )
	LogWrite:flush()
	LogWrite:close()
	
	counter_WIZVAR = 1
	else
	counter_WIZVAR = counter_WIZVAR + 1
	end
			
end

do_every_frame ("failedMTBF()")

 

I think this looked good.. Will do some more testing and probably include it in the next version. 

Link to comment
Share on other sites

You could also implement some kind of failure level. Maybe 1,2,3 where 3 triggers the badass failures. 1 triggers the "light" ones and 2 the "medium" ones. This ensures that the user can finish his flight when chosing the lower levels. Sometimes you want to reach your scheduled location :-)

Edited by Cosmopilot
  • Upvote 2
Link to comment
Share on other sites

56 minutes ago, Cosmopilot said:

You could also implement some kind of failure level. Maybe 1,2,3 where 3 triggers the badass failures. 1 triggers the "light" ones and 2 the "medium" ones. This ensures that the user can finish his flight when chosing the lower levels. Sometimes you want to reach your scheduled location :-)

Yeah.. That could be a good idea. Thanks for your suggestion.

 

45 minutes ago, mfor said:

Nice testing - looks like it's working as intended.

Probably a good idea to make the test variable local as well (or get rid of it) just in case - forgot that in my suggestion... LUA is weird :blink:

Everything is local in the script. Learned that the hard way :)

Also did some more MTBF testing, now with 10 hours.

uXESXij.png

 

I see a tendency that the average is slightly below the MTBF. But could be the low amount of samples maybe.

I have implemented this in my script now, so only some internal testing left :)

 

Link to comment
Share on other sites

Just now, Tom Stian said:

I see a tendency that the average is slightly below the MTBF. But could be the low amount of samples maybe.

Most likely - I did a quick test on the online lua site (https://www.lua.org/cgi-bin/demo) and with 100 samples I would see numbers from 7.5 to 12.5 hours within a few clicks.

OTOH I don't know how good the lua rand function really is.

Link to comment
Share on other sites

On 4.6.2017 at 5:29 PM, Cosmopilot said:

You could also implement some kind of failure level. Maybe 1,2,3 where 3 triggers the badass failures. 1 triggers the "light" ones and 2 the "medium" ones. This ensures that the user can finish his flight when chosing the lower levels. Sometimes you want to reach your scheduled location :-)

I have tried to rank the failures. 

Light	
	BATTERY BUS
	DC BUS 1 and 2
	DC STANDBY BUS
	GENERATOR BUS 1 and 2
	MAIN BUS 1 and 2
	ENGINE HYD PUMP A and B
	ELECTRIC HYD PUMP A and B
	EDP A and B FAST and SLOW LEAK
	SYSTEM A and B Fast and SLOW LEAK
	
Medium	
	AC STANDBY BUS
	AC ELECTRONIC 1 and 2
	DC ELECTRONIC 1 and 2
	ENGINE 1 and 2 FIRE
	ENGINE 1 and 2 FAILURE
	OIL PUMP ENGINE 1 and 2
	
BADASS	
	TRANSFER BUS 1 and 2
	HOT BATTERY BUS
	SWITCHED BATTERY BUS

This is what I came up with so far.

Im a bit unsure about the HOT BATTERY BUS. Not sure really what the failure do.
And if ENGINE FIRE and FAILURES  and OIL PUMP ENGINE 1 and 2 should be on medium. All results in engine stop.

Link to comment
Share on other sites

32 minutes ago, Tom Stian said:

Im a bit unsure about the HOT BATTERY BUS. Not sure really what the failure do.
And if ENGINE FIRE and FAILURES  and OIL PUMP ENGINE 1 and 2 should be on medium. All results in engine stop.

Hm, after thinking a little bit about it, the classification into 2 categories would make more sense. Just "Flight can be continued if the failure occures" and "Divert to neares suitable".

Link to comment
Share on other sites

On 5.6.2017 at 6:30 PM, Cosmopilot said:

Hm, after thinking a little bit about it, the classification into 2 categories would make more sense. Just "Flight can be continued if the failure occures" and "Divert to neares suitable".

Ill think I go for the 3 failure levels as I ranked above.  so basicly level 1 is "You can continue without major issues", 2 is "You should divert ASAP", 3 is "You should divert ASAP, and good luck" :) 

Link to comment
Share on other sites

  • 1 month later...
On 26.5.2017 at 6:07 PM, Tom Stian said:

A little story from my last flight.

Had a interesting flight yesterday between LSZH (Zurich) and ESSA (Arlanda) during a VATSIM event, when a failure was triggered.

Its fun to (try) troubleshooting and find out what has happend without looking at the logfile or the failures menu.

[...]

 

Coincidently, Jan once did a video with a Hyd B leakage... (it was a slow leak, but with the same final results :D)

 

Link to comment
Share on other sites

26 minutes ago, daemotron said:

Coincidently, Jan once did a video with a Hyd B leakage... (it was a slow leak, but with the same final results :D)

 

Nice one.. I have seen all the videoes pre the release. But actually forgot that one.. So I guess you have the answer how it should be done there ;)

One difference was that I was setting the VREF to + 15 knots for the flaps 15 landing. Maybe I did misunderstand the QRH checklist.

Link to comment
Share on other sites

To quote Mike Ray:

Quote

REF - this is the speed for a specific flap configuration (for example Flaps 30 = 30 REF)

TARGET SPEED - this is the REF speed corrected for the wind component. It is the speed that we use to fly the approach. It is equal to: REF + 1/2 the STEADY WIND component + FULL GUST value. The maximum correction for the wind is not to exceed 20 Kts.

TOUCHDOWN SPEED - this is the speed at which we LAND the airplane. That is, after the flare and approaching the runway. It is equal to: REF + the FULL GUST value. The maximum gust correction not to exceed 20 Kts.

So if you're flying without any wind, the correction would be zero => you set the REF speed on the MCP (plus a gust margin).

Link to comment
Share on other sites

11 hours ago, daemotron said:

To quote Mike Ray:

So if you're flying without any wind, the correction would be zero => you set the REF speed on the MCP (plus a gust margin).

Not sure about other airlines but we used a minimum correction of 5 knots. So no wind target is Vref+5.

Cheers Jan

Link to comment
Share on other sites

Hi Jan,

I'm not sure I really understand the story of wind correction. Does it mean you apply min +5 Kts for gust precaution, and more if heavier gusts are announced?

For the gust margin, it seems conceptually obvious to me (to avoid dropping below VREF due to wind gusts). But for the steady wind correction, I'm not really sure what the purpose is - the VREF is indicated airspeed after all (at least I thought so), so why is there such a correction to be applied? Can't be to ensure hitting the right IAS...

Cheers
Jesco

Link to comment
Share on other sites

22 minutes ago, daemotron said:

Hi Jan,

I'm not sure I really understand the story of wind correction. Does it mean you apply min +5 Kts for gust precaution, and more if heavier gusts are announced?

For the gust margin, it seems conceptually obvious to me (to avoid dropping below VREF due to wind gusts). But for the steady wind correction, I'm not really sure what the purpose is - the VREF is indicated airspeed after all (at least I thought so), so why is there such a correction to be applied? Can't be to ensure hitting the right IAS...

Cheers
Jesco

Im not sure at all. But I think it I read somewhere that one reason for this is that the autothrottle is certified for +/- 5 knots. So setting speed to VREF +5 will avoid getting below VREF  when autothrottle are engaged.

Edited by Tom Stian
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...