FMC Lockup EGLL Star

[cmpbellsjc 2,960]

I've been having some issues lately around EGLL. I never flew into that airport until recently having purchased the UK2000 version and I've had everything from ASN crashing there, black screen crashes after landing and then tonight after another try, I got the FMC to lockup after trying to delete a waypoint in a STAR.

 

I flying from KJFK with a PFPX route. 22R departure using GREKI4.JFK and the EGLL KENET.OCK1A arrival with the OCK transition I think it was, and ILS 27R approach.

 

I was flying off line and wanted to delete some of the altitude restrictions, specifically the D076K 220/6000A restriction. Using the Delete button and the corresponding LSK to delete 220/A6000 nothing would happen. I even tried the entering 220/6000 and that wouldn't work. I then tried moving the next waypoint up to essential get rid of D076K and then the FMC froze up and gave me some other options (none noted or screen shot). This was using the left FMC controlled by Shift 2.

 

I was able to use the center FMC I believe it was, the one linked to Shift 3 and retrieve the flight plan. After cycling both FMCs around I was able to unfreeze the left FMC and use it, until I was on final and got the black screen crash with skipping sound and had to reboot.

 

I've only been able to make a few successful landings and taxi to gate here without the black screen crash and am wondering if it's related to faulty FMC info.

 

I never have any OOM or FPS issues, so I can rule out that. Typically according to FSUIPC I have around 1.5GB of VAS available when I black screen crash and FPS are always in the mid 20 to high 30s and smooth.

 

Event viewer never turns up errors and I was only able to get one mini dump that after uploading for analysis pointed to a Video_TDR_Timeout pointing to an nVidia nvlddmkm module.

 

I'm running FSX SP2 on Win7 64, 2700K not yet overclocked and a GTX670. I'm using fairly older drivers 301 something as they have been stable for me the last 3 years.

 

I'm able to fly either the NGX or T7 to any of my payware airports anywhere in FSX with absolutely no issue and have never had any issues with FSX since 2008, going back to my old rig and now this one, but for some reason this airport with the T7 has been giving me fits for the last two weeks.

 

Not sure if the crashes can be attributed to the FMC cycle I am running which is the April-May cycle that just expired or I somehow have a corrupt driver. The only thing else I can think of is that I've had some storm related power outages lately, sometimes in mid flight and other ones with the computer running.

 

Any feedback would be welcome before I either consider not flying to EGLL anymore or try the new Aerosoft version.

 

 

Thanks,

 

Sean Campbell

[kevinh 409]

I doubt a lock up in the FMC has anything to do with the scenery unless it is VAS related. You could try disabling UK2000 EGLL in the scenery library and seeing if the same problem occurs. Deleting altitude restrictions certainly isn't scenery related and I would ask why bother? Deleting restrictions on departure can make life easier by allowing a faster climb but on approach I find they rarely get in the way.

 

I've had lock ups when accessing the FMC many times and I think this is because of a temporary but rapid increase in VAS usage caused by the FMC. FSX disk is very prone to VAS problems and the longer your flight the worse it gets. The 777 is a big user of VAS so that won't help. Since switching to FSX-SE, which fixes the memory release bugs in FSX, I haven't had any such lock ups.

[cmpbellsjc 2,960]

I don't think Kevin or Jim understood the question very well.

1.5Gb of remaining VAS should be more than enough but if the FMC is locking up when trying to delete a waypoint then maybe someone is wrong with the AIRAC data.

 

 

 

 

MOD EDIT: Removed tangential discussion. 

[vc10man 732]

Sean, if it is any help, I too run the same aircraft under FSX-SE, and use the same UK2000 EGLL, and ASN,---- and incidentally, I've no had issues with it at EFLL or anywhere else for that matter, and PFPX too. Nor have I never encountered any issues with the T7's FMC when changing waypoints making the approach into EGLL to match a parallel-running AivlaSoft flightplan.

 

Hope you get it sorted soon.

[kevinh 409]

I don't think Kevin or Jim understood the question very well.

 

1.5Gb of remaining VAS should be more than enough but if the FMC is locking up when trying to delete a waypoint then maybe someone is wrong with the AIRAC data.

 

 

 

 

MOD EDIT: Removed tangential discussion. 

Jim, I understood the question perfectly well. I just think it is wrong to discount VAS so easily. The T7 is notorious for high VAS usage and it won't be any lower on the OP's system. I don't know how current FSUIPC's measurement of VAS usage is or how complete that calculation is.

 

If there was an AIRAC error around EGLL it would not be scenery related, it would occur with default scenery too. Anyway, that area is fairly heavily used so I think others would have noticed a problem with that cycle. I think the problem is not AIRAC but the FMC being asked to do additional recalculation and data manipulation with a complex scenery loaded. It might not be an OOM but it could be to do with corrupted memory addressing in some other way.

[downscc 1,327]

There is a problem in the 777 FMC at EGLL. It's been discussed in the beta channels and I assume it's in the bug tracking system.  The work around is easy because the problem appears to be in the approach transition.  For example, using the OCK STAR (I don't have my charts open so exact names missing) create a PDB waypoint after OCK VOR for the R-076 12DME fix and hand fly or use MCP to maneuver base and final intercept to 27L/R.  Don't select the ILS OCK transition.

 

This error is not in the Navigraph data.  Your locked FMS will behave normally after deselecting the OCT transition.

[cmpbellsjc 2,960]

I doubt a lock up in the FMC has anything to do with the scenery unless it is VAS related. You could try disabling UK2000 EGLL in the scenery library and seeing if the same problem occurs. Deleting altitude restrictions certainly isn't scenery related and I would ask why bother? Deleting restrictions on departure can make life easier by allowing a faster climb but on approach I find they rarely get in the way.

 

Kevin, thanks for the reply. I don't think the VAS is an issue since I have ample remaining VAS available, around 1.5gb and I get none of the OOM chimes from FSUIPC and FSX never closes with the OOM message about running out of memory.

 

Also, I can load the T7 at EGLL and fly circuits, land, taxi, takeoff again, etc, with no issues with the FMC not programmed.

 

However, when flying to EGLL after getting the FMC locked up and way points that I couldn't change or delete, I assumed something else is going on here. I can usually land on 9L and get off the runway before the black screen crash and not have any FMC issues on 9L, but on 27R tonight I got the lockup and then the black screen while on final.

 

I don't belive it's the actual airport but with its unusual plumbing style AFCAD that throws a ton of ADEX errors I was thinking that when I crash on the ground after landing that it might be contributing to the error.

 

Plus EGLL and the surrounding area isn't more demanding than other areas like JFK OR SEA on my system and have no issues there.

 

 

Sean Campbell

There is a problem in the 777 FMC at EGLL. It's been discussed in the beta channels and I assume it's in the bug tracking system. The work around is easy because the problem appears to be in the approach transition. For example, using the OCK STAR (I don't have my charts open so exact names missing) create a PDB waypoint after OCK VOR for the R-076 12DME fix and hand fly or use MCP to maneuver base and final intercept to 27L/R. Don't select the ILS OCK transition.

 

This error is not in the Navigraph data. Your locked FMS will behave normally after deselecting the OCT transition.

Thanks Dan, that is good to know that it's a known issue at EGLL.

 

I'll try another flight with your work around and see if that solves the issue.

[cmpbellsjc 2,960]

There is a problem in the 777 FMC at EGLL.

Dan, you may be onto something here.

 

I tried the same flight tonight, JFK to EGLL. The flight plan was similar and called for the same STAR and 27R. This time as a test I didn't even select the STAR and just selected the ILS 27R approach and left the last way point from the flight plan as KENET and basically just self vectored myself on a left hand downwind to a left base to intercept the FAF.

 

Last night when I crashed I was on final to 27R and didn't even make the runway. This time no issue but was crossing my fingers as its a long flight to waste with crash at the end, but all went well. Landed and taxied to the gate and had 1.6GB VAS remaining and had a solid 35 FPS on approach.

 

I guess going forward at EGLL I'll just do the same from now on until a fix is published.

 

Although this was just one flight, it has been one of the few here that didn't end in the dreaded black screen so I'd consider it a step in the right direction.

 

Thanks for the help Dan.

 

 

Sean Campbell

[kevinh 409]

There is a problem in the 777 FMC at EGLL. It's been discussed in the beta channels and I assume it's in the bug tracking system.  The work around is easy because the problem appears to be in the approach transition.  For example, using the OCK STAR (I don't have my charts open so exact names missing) create a PDB waypoint after OCK VOR for the R-076 12DME fix and hand fly or use MCP to maneuver base and final intercept to 27L/R.  Don't select the ILS OCK transition.

 

This error is not in the Navigraph data.  Your locked FMS will behave normally after deselecting the OCT transition.

Very interesting Dan, that would explain it. I haven't noticed the problem and I fly the 777 a lot around EGLL. It hasn't cropped up on the BAVirtual forum either, and there are many 777 users there flying into Heathrow. However usually you go straight from the STAR to ATC vectoring so problems in the transition would not get noticed.

 

 

Kevin, thanks for the reply. I don't think the VAS is an issue since I have ample remaining VAS available, around 1.5gb and I get none of the OOM chimes from FSUIPC and FSX never closes with the OOM message about running out of memory.

 

Also, I can load the T7 at EGLL and fly circuits, land, taxi, takeoff again, etc, with no issues with the FMC not programmed.

Yes, given Dan's post it's clearly not VAS or memory related. Glad there's a workaround. Something to remember when I'm flying the 777 into LHR until the fix is produced.

[cmpbellsjc 2,960]

Yes, given Dan's post it's clearly not VAS or memory related. Glad there's a workaround. Something to remember when I'm flying the 777 into LHR until the fix is produced.

I knew that from the onset, given that 1.5gb of VAS available is not even close to flirting with an OOM. Had I been 500 or lower remaining then I would have considered it, but even then I would have had warning signs.

 

 

As an update I did another flight from Nice to Heathrow tonight and got 27R again. Skipped loading the STAR and just loaded the ILS 27R approach and was able to land and taxi to the gate with no problem.

 

Seems skipping the STAR completely or manually entering it fixes the problem here.

 

 

Sean Campbell

[kevinh 409]

I knew that from the onset, given that 1.5gb of VAS available is not even close to flirting with an OOM. Had I been 500 or lower remaining then I would have considered it, but even then I would have had warning signs.

 

 

As an update I did another flight from Nice to Heathrow tonight and got 27R again. Skipped loading the STAR and just loaded the ILS 27R approach and was able to land and taxi to the gate with no problem.

 

Seems skipping the STAR completely or manually entering it fixes the problem here.

 

 

Sean Campbell

Bear in mind that you can get memory addressing problems even if well within VAS limits. A corrupt address in the code for example. In this case the FMC code might be being corrupted by the STAR transition waypoint data and causing a crash due to an incorrect memory address.

 

From what Dan said the problem is not the STAR itself (which in this case finishes at the OCK hold). It's the VIA transition from the STAR to the runway which causes the problem. You should be able to load the STAR and then follow ATC vectors.

Just don't select a VIA with the STAR.

[downscc 1,327]

 

 

From what Dan said the problem is not the STAR itself (which in this case finishes at the OCK hold). It's the VIA transition from the STAR to the runway which causes the problem. You should be able to load the STAR and then follow ATC vectors.

 

Exactly, thanks Kevin.

[cmpbellsjc 2,960]

There is a problem in the 777 FMC at EGLL. It's been discussed in the beta channels and I assume it's in the bug tracking system.

Dan, is this problem at EGLL related to all STARS and VIA transitions from approaches or just specific to the OCK transition?

 

I have not tried actually loading the STAR and ILS approach without the transition yet, I've just tried the two flights using only the ILS with the FAF it loads and then self vectoring from the last waypoint. Frankly I'm scared to load the STAR and then the ILS approach even without VIA transition, just due to the time it takes to do the test flight then crash the sim, but I'll give it a go since the weekend is here and see what happens.

 

Do you know of any other airports in the bug tracking system with similar problems we might want to avoid or use this work around? I haven't had this issue with any other well known large or small hubs, but thought it would be worth asking just to be safe.

 

Thanks,

 

Sean Campbell

[downscc 1,327]

 

 

Dan, is this problem at EGLL related to all STARS and VIA transitions from approaches or just specific to the OCK transition?

 

I've only examined the IAP OCK transition.

 

I have had at least two or three sessions using the OCK STAR and ILS27L/R IAP without transiton without problem. You should try it.  As mentioned, I extend the downwind from the VOR with a waypoint at OCK076/12 and cross it at 6000 before starting a turn to base but that's just personal preference. I don't use VATSIM or equivalent.

 

Looking at the transition in the sidstar file: 

TRANSITION OCK FIX OCK 7000 SPEED 220 TRK 076 UNTIL 7.0 FROM FIX OCK SPEED 220 FIX D076K AT OR ABOVE 6000 FIX OVERFLY D076L HDG 359 INTERCEPT RADIAL 065 FROM FIX OCK HDG 359 INTERCEPT RADIAL 271 TO FIX CI27L

 

There is nothing wrong with the syntax from Navigraph, but the current version of 777 FMC logic chokes on something in it and I've not dug into it but suspect the floating waypoints introduced with the overfly then heading then intercept radial... I think the double floating waypoints are too much for it.  (floating waypoint means there's no way to establish exactly that point in space, as in "track 090 until 1000" where the point that you reach 1000 depends on climb rate, speed, wind etc). The same double floating waypoint issue was the problem with the missed approach procedure for KLAX ILS27L I think.

 

Simply don't use the transition.