[SOLVED] duplicate waypoints in approach and missed approach

[Stephane LI]

Hello,
it's a little bit difficult to explain this issue so I will try my best.
When a waypoint is part of an approach procedure and the same waypoint is also part of the missed approach, cleaning a discontinuity with this waypoint erases all route after this waypoint including CF, IF, RWY etc, like if we want to go direct to this waypoint in the missed approach procedure. I don't think it is a correct behaviour.

How to reproduce:
- Situation FMEE Runway 12
- for the route enter FMEE as departure, and FMEE as arrival. Just to perform a circuit around the airport
- for the SID runway 12, choose DOBU1J.
- for the approach choose and RNAV runway 14.
- first issue: I can't choose OKNER as the transition point as OKNER is part of the missed approach.
- so forget about the transition and activate, Execute.
- Next step: I don't want to fly to DOBUT but I want to shorten my circuit by removing BAPAD and DOBUT. I want my route to be something like LAKAZ, ODAVI, VEKAS, OKNER, TESOP, EE408, RWY14, (470), LAKAZ, OKNER.
- I type OKNER in the scratchpad and line select it over BAPAD to replace BAPAD by OKNER. The result is that all waypoints are removed until OKNER which is part of the missed approach.
- For the time being my workaround is to delete BAPAD and DOBUT and cleaning the discontinuity by line selecting TESOP and put it over the discontinuity line.
- Another workaround would be to delete the waypoint in the missed app procedure, insert the waypoint in the route sequence then insert this waypoint in the missed approach procedure again.

Maybe I may have missed something?
But in case of an engine failure after takeoff we should be able to enter DCT OKNER in the FMC and fly the RNAV approach procedure without going directly to the waypoint OKNER in the missed approach procedure.

Stephane

[Hardy Heinlin]

Hello Stephane,

before I read your complete post ... one question: Which PSX version are you using?


|-|ardy

[Stephane LI]

10.53. I've just downloaded it early this evening  and my navdata is 2017 one. I did not update the db this year.
Stephane

[Hardy Heinlin]

I just tried your steps and I got none of the problems you mentioned.



--------------------------------------------------------------------------

Your comment in italics, my comment in bold font:

How to reproduce:
- Situation FMEE Runway 12
- for the route enter FMEE as departure, and FMEE as arrival. Just to perform a circuit around the airport
- for the SID runway 12, choose DOBU1J.
- for the approach choose and RNAV runway 14.
- first issue: I can't choose OKNER as the transition point as OKNER is part of the missed approach.
I can select OKNER -- no problem.

- so forget about the transition and activate, Execute.
- Next step: I don't want to fly to DOBUT but I want to shorten my circuit by removing BAPAD and DOBUT. I want my route to be something like LAKAZ, ODAVI, VEKAS, OKNER, TESOP, EE408, RWY14, (470), LAKAZ, OKNER.
- I type OKNER in the scratchpad and line select it over BAPAD to replace BAPAD by OKNER. The result is that all waypoints are removed until OKNER which is part of the missed approach.
I select it over BAPAD and all is fine: I get LAKAZ, ODAVI, VEKAS, OKNER, TESOP, EE408, RWY14, (470), LAKAZ, OKNER.

But in case of an engine failure after takeoff we should be able to enter DCT OKNER in the FMC and fly the RNAV approach procedure without going directly to the waypoint OKNER in the missed approach procedure.
I see no problem. The DIRECT always shortcuts to the first occurance of the fix if multiple clones of that fix exist.

--------------------------------------------------------------------------



Of course, if just one fix AAAA exists in the LEGS, entering AAAA in 1L will make a direct to that AAAAA. That's a fundamental FMC rule.

The only problem you have is you didn't select OKNER as a transition on the ARRIVALS page.

[Jeroen Hoppenbrouwers]

Just asking, Hardy:

If you have two occurrences of the same waypoint, say POINT, in your route... does it matter at all whether you:

1. Type "P O I N T" directly into the scratch pad,
2. Downselect the first occurrence of POINT,
3. Downselect the second occurrence of POINT?

Not one POINT in Africa and one POINT in Asia -- really the same POINT.

Hoppie

[Hardy Heinlin]

It doesn't matter. The scratchpad information consists of 24 bytes for the text. No room to store any array index from a previous downselection in an additional byte.


|-|ardy

[Stephane LI]

Hello Hardy,
I will try to make a quick video tonight after work.
Maybe it is something on my side not doing things correctly. But i did the same manipulation in the other B744 simulation in P3D and it works as it should be.
Stephane

[Hardy Heinlin]

it works as it should be

Is your reference the real 744 FMC? And to be more specific: Is it the real "legacy" 744 FMC (not the 744 NG FMC)?

Do you understand my answers above? It's not about the question whether you are doing something wrong. The effect you are seeing is intentional. I programmed it so that the first occurance is the target of the direct. If there is only one occurance, then that is the target, even if the target is a missed approach fix.

Are you saying that there is a real FMC version that doesn't accept a direct-to to a missed approach waypoint?


|-|ardy

[Hardy Heinlin]

Hoppie, 20 years ago in PS1 I actually used a special system status flag in addition to the scratchpad memory. The flag told the program whether the text was typed or downselected. When the text was upselected, the direct-to logic only ran if the flag had signalled a downselection. The disadvantage: The status wasn't indicated to the user; when you load a situ file with a text in the scratchpad or when you leave the sim for while and return, you don't know if this text has been typed or downselected. For example, for words like "DELETE" you know whether the word is typed or not by checking the MSG light. There's no such indication for arming the direct-to function. So I removed that status flag some years later. I think the removal agreed with observations on the real FMC at that time. But I'm not sure anymore. I see the feature also had its advantage.


|-|ardy

[Stephane LI]

I just tried again tonight and now it is ok.
I think it's because I had a previous route loaded and activated in the FMC (from FMEE to FIMP) and I was just replacing FIMP by FMEE as destination yesterday.
Tonight I have completely erased the route in the FMC by entering FMEE as departure airport first, then as destination airport. Then I could enter the whole route sequence in the FMC.
Sorry for this.

Stephane

[Hardy Heinlin]

That's impossible :-) You suggested that it should work as you described above. The version you're using is intentionally programmed so that it won't work as you described.

Why don't you answer my questions? Whenever I ask a user a question, I ask because I want to learn something and possibly modify my code accordingly. I'm not asking for fun.


Regards,

|-|ardy

[Jeroen Hoppenbrouwers]

I actually play with the idea that the FMC may internally know very well what waypoint was downselected, and does not at all reduce all the database information sitting under exactly that waypoint to max 24 characters. No you don't see this, but it would make sense.

I am too lazy to try it... what would happen with downselecting waypoints that are by definition not expressable in just characters? Like conditionals? Or when downselecting a waypoint that is known to have a name-duplicate somewhere else in the world -- if it is upselected, does the FMC ask explicit deduplication, or does it know what it got in the first place? Etc.

I have that belly feeling that if more details of a waypoint beyond its plain character projection are known to the FMC, and you downselect and do not at all touch the scratch pad, it will move a database entry, not a character string. Even if it does not show this.

Hoppie

[Hardy Heinlin]

We did a lot of tests in the past decades. For example, there's that rule which only shows the SELECT DESIRED WPT page when the entered identifier does not exist in the current route. If it already exists, a duplicate of that existing route waypoint will be entered -- unless its entered directly under the existing waypoint in which case a route disco will be inserted there instead of adding a clone directly thereafter.

I don't think that the real FMC stores the downselection index; it quickly gets chaotic and out of sync when waypoints are being sequenced or RTE page edits are done on the other CDU etc. I can only imagine that it keeps the "downselected or typed" info as I wrote above, like in PS1; so when typed, the direct-to function will simply be inhibited.

Of course, a leg data record consists of much more than just its waypoint identifer. The sratchpad only shows the identifer or the extended position format if it's a PBD, PBPB or Lat/Lon. There are pointers to the respective fixes in the nav database, and to data of pilot entered fixes (PBD etc.).


|-|ardy