FMC Glitched and Locked Out

[kieranharvey95]

Hiya,

Loving the update!

Came accross an issue during a flight from PHNL-PHKO however. Route PALAY2 LNY VECKI9.

If you input the PAYLAY2 with LNY trasition via Arr page then go into Dep page and try to input VECKI9 with LNY transition, then input the ILS 17. Loads of red text is thrown up in the debug box and the FMC locks you out, all screens freeze and you are left with only VOR's to navigate. Killed my flight.

The workarond for me seemed to be inputting the Runway and ILS before selecting arrival, but you should be able to do it in STAR>RWY order, as you often won't know your runway until close to the field.

Is this a known bug, haven't tried with any other route, possibly a not forseen bug based on a SID and STAR sharing the same Transition (LNY)?

If you could fire up the sim and try setting up at PHNL and inputting the plan as you normally would you should replicate the issue.

Cheers,

Kieran.

P.s. Latest Airac - Navigraph, re-installed IXEG and tried on shipped Airac, same issue, not Airac issue.

[Litjan]

Hi Kieran, thanks for the nice words and the bug report!

We are always very keen on getting data to replicate these code crashes - I will try to input your routing when I get home and hope that I also get the crash - then forward it to Tom.

There are often STARs or SIDs that pertain to many runways - but sometimes are even laterally dependent on which runway they serve. So for us it is hard to decide which on the different "versions" to load before the user has specified the runway.

We certainly endevour to fix that - by possibly holding all display of routing until a runway has been selected - but often users don´t do that until the flight nears the destination...so they get confused about the STAR not being in the LEGS page (because we don´t know WHICH one to show yet).

So indeed - the easiest way to do it (and the way I was taught to do it in the real 737) is to always start with the runway (for both SID and STAR) and then work your way "inward". If you don´t know the runway yet, just put in the most likely and then change it enroute when you get closer.

Cheers, Jan

Edit: PS if that ever happens enroute you can at least "save" your flight somewhat by rebooting gizmo...you will be in the same spot, but of course you would have to set up your systems again as the reboot resets everything to default values

Edited May 27, 2020 by Litjan

[kieranharvey95]

Hiya,

Thank you for the response appreciate it

I can confirm I redid the entire flight earlier today and inputting the runway before the STAR worked perfectly, route drew nicely and all worked as expected. Was literally just the inputting the STAR before. I will from now on follow that advice, just take a good guess at the runway, can always change it.

I did not know you could reboot Gizmo either, thanks for the tip, and if it at all is of relevance I was using the BETA Gizmo?

Will carry on enoying this for a long time to come!

Kieran.

[Litjan]

Hi Kieran,

I don´t think that using the BETA Gizmo had anything to do with it.

Happy landings! Jan

 

[tkyler]

On 5/27/2020 at 8:04 AM, kieranharvey95 said:

The workarond for me seemed to be inputting the Runway and ILS before selecting arrival, but you should be able to do it in STAR>RWY order, as you often won't know your runway until close to the field.

This is one of the major areas that will be fixed by switching to the XP1100 navdata set.  The XML data format does not delineate between the "runway transition" portions of a STAR vs the common portions very well at all.  If you enter a STAR and the runway isn't entered yet, then ideally it should either 1) load the common part of the STAR, until the runway is selected or 2) let you know that a runway selection is required. (which does exist in some cases)

The XML format we use is proably 15+ years old and just not the most flexible format.  While this can be coded around, the code turns in to bloat very quickly with this XML format.  I can't wait to move from it.  Maybe I'll think of something clever or have some aha moment to get this to work with this format until then.

-tkyler

[tkyler]

So I have recreated it....and will take a stab at it.  This one rears its ugly head from time to time and I'd love to get it fixed (as would everyone else I'm sure!)

-tkyler

[tkyler]

For the life of me, I have a line of code that says, "if the arrival runway is selected, append the star transition points".  I remove that condition and everything snaps into place on this particular procedure (still a tweak to RTE  page required though).   I can't recall what kind of situation made me put that in all those years ago (though I'm sure some other user will find it).  Transitions were particularly challenging given the XML dataset I originally started with, that I do remember...and one provider had runway transitions and another didn't.  Things seem to have leveled out over the years, but this old code remained.  I can only wonder how this may clean up other calculations on the descent side of things. 

 

 

Edited June 8, 2020 by tkyler

[tkyler]

so digging a little deeper, I now recall why I had that line of code in there...and why we need to switch over to the XP1100. nav data format.   The problem is the XML format we use does not represent "common" portions of STARs such as is found at KBOS.  In this particular example above, the STAR serves 'all' runways, indeed that is the exact word the XML format uses for this star..."ALL".   BUT at an airport like KBOS, a STAR will serve a bunch of runways and perhaps only the first few points of the STAR may be common before it diverges to specific runways.  So if a runway was NOT selected, but a STAR was,  then you would at least expect the common points to load; however, the XML format associates waypoints with runway identifiers in this case...and without a selected runway, I don't know which XML block to load.   There is an extremely cumbersome workaround of trying to extract the common points, but it is not worth the effort IMO, and switching to a more realistic data format is the prudent solution....putting a giant band-aid on what we have is not the way to go.  

SO....what this means is when you select this type of STAR, that is associated with specific runways (as opposed to ALL runways), then we will pop a CDU message saying, SELECT RWY FIRST".  When you do this, then you can select a STAR and it will load the STAR associated with the runway selected...inlcuding the "common points".  Then, as mentioned above, you can select a new runway after you know which one you'll get, but at the least we'll avoid these gizmo erros ruining the flight.

We avoided this message earlier because it simply wasn't like the real FMS, but neither is the nav data format and so its finally time to compromise.   Unsure if we'll get this into the next patch...as we want ample time to test it.  Certainly entering the runway first now before selecting stars is a good protection.

-tkyler

Edited June 9, 2020 by tkyler