Sorry, are you saying that in step 4 you loaded an arrival procedure just as you got to the last fix of the SID, and it loaded one for your departure airport, not the destination airport?
Correct!
but you can do that and test if you have some similar situation. It set simply track from departure airport to that fix, completelly outside of my actual (SID). PMDG 737 did all excellent!
So what happens if you load your SID, and Arrival procedures on the ground, before take off?
Not my intention,
why I need load ARR on departure airport??? 
I load ARR in good to me distance when I’m clear of destination conditions, this means of course also approach type. Arrival procedure can be different at time you arrive ARR init fix, due wind and therefore different rwy in use.
You wouldn’t be. The arrival procedures listed would be for the destination airport you already have programmed in.
But you are right, you might need to use a different approach. but you can always load a new one if the currently loaded one is no longer applicable. I was just trying to see if it made a difference if it was already loaded, rather than being picked while in flight, and at the end of the SID. I can’t see how an approach for the departure airport could be loaded.
Look,
I’ve set that ARR in middle of SID as I said, pretty ok to me to be correctly with arrival airport conditions, nothing special. Again, PMDG did all as expected In case I did as you said, in very close distance to last SID fix, Garmin send me to back to airport of departure 
Again pls, try change in time of arrival and hard atc talks on freq due hard traffic at arrival airport to fight with all things again sry, not to me.
That’s definitely not what I would expect or at least hope. Have you tried the same process on the 750?
But this is initial of all what I did yesterday and today
I’ve discovered all with use of GTN750, this gives me idea to do some test flights and there I discovered that strange other things. On other side, all of that addons use stock or WTT system so all are in trouble now Simply system is working now like that, all stock and WTT systems are working as are, with some not specific situations maybe ok but on my mentioned, wrong. This is also maybe my luck because I never discovered this also with TBM and WTT G300 till this time, only after I’ve decided use my mentioned departure and arrival airports as my test flight to GTN750
Could you give an example with the smallest possible FP and precise repro steps so we can test?
I can understand such issues with the stock flight planner that is buggy. The WT one should work.
Do you have the same issue with the G1000Nxi?
2 Likes
Hello,
pls read my posts again carefully, there is report that TBM with WTT G3000 do also same problem, also same with your GNS530 (as you said use stock planner system) and Nxi. My test place:
FPL set →
dep airp ->LZIB rwy31
arr airp → LZPP
-due use of rwy31 I set SID NIT1A
-SID is ok inside Garmin
-airborne, use GPS nav (FMC option)
-at posit what you want (I set LZPP arrival procedure after estab track to NIT on SID, after passing INTRCPT).
-after set NIT2P arr to Garmin - bang, look at picture:
My actual track (my aircraft position) was replaced with that new mentioned from LZIB to NIT. Stock Asobo (also with your GNS530), WTT Nxi and WTTG3000 did same mistake. I’ve filled FPL inside Garmin, its only DEP and ARR airports and LZIB SID, nothing special. PMDG did this correct.
I hope you’ll sort this without problems, then Garmin navigation types can work as expected 
Very appreciated and now I enjoy to better functionality.
I’m available to any tests what you expect to do, no problem but time is my boss I think all is ok if aircraft simply continue as is on FPL, no need do any other changes in system. I expect then after NIT it will do turn and start do arrival procedure what is correct to me.
Update: do pls maybe other airports situation, will also do for sure.
There are dedicated PMS threads where you can ask this question, as well as the PMS Discord. Recommend you ask there to keep this thread focused on G1000. Thanks.
Thnx for info,
no Discord to me, closed that in 2019 due many spams. On other side this isn’t PMS issue.
IMPORTANT UPDATE:
And here we go again Did test on other airports where all was set ok, as need to be. Due my investigations before, it looks like some problem with airport LZPP??? Pls do tests on other airports and confirm pls. Then if it’s true, it’s same problem like I reported inside your GTN750 topic (nothing to do with GTN750) but again pls, be careful! Why then PMDG do this procedure correctly on my mentioned problematic flight LZIB-LZPP? Look again pls to your GTN750 topic about my mentioned SID problem from LZPP and offset. If you see there correctly, WTT G3000 hasn’t problem but Nxi yes Really tired of that situations, what’s matter.
If you have the same issue with the G1000Nxi I can suggest you to ask directly to WT people. They have a very good knowledge around all that and for sure, they will fix it if there is an issue.
There is a dedicated discord channel where they answer immediately.
The discrod channel is Discord
This is the place to go.
1 Like
Am I the only one that can’t replicate this?
Mine seems to work fine as long as I use XENDI transition.
Just a warning, this is going to get technical, because this is a very complex navdata and flight path vectorization issue.
This is an extremely specific issue that will only occur in precisely the situation that has been set up:
- The last two legs of the SID is a leg of type VI (heading to intercept) then type CF (course to fix)
- The first leg of the arrival is a duplicate ICAO leg of type TF (track to fix)
- The VI leg of the SID is of considerable distance (most are very short, less than 1NM, unlike this intercept leg)
The Garmin units normally run a leg deduplication procedure if they encounter duplicates in sequence which keeps the type of the second leg and not the first. So, that’s what we do in this situation. This causes the intercept to then become zero length, because the CF leg is now replaced with a TF leg (the leg type on the arrival), which will originate from the end of the 900FT heading to altitude leg. Thus your leg’s track will shift when the arrival is added.
Looking at the actual unit for reference, it appears that in this single specific case (and no others I can find), it opts to keep the previous leg type instead of the later leg type, leaving the CF in place at a course of 082 degrees. Since there are almost an infinite combo of leg sequences, this is just one case we have never seen before.
To be fair to us, the actual unit also handles this worse in one aspect: once you load the arrival, it freaks out and makes the active leg the 900FT leg, which is pretty annoying. As any pilot who spends a lot of hours with any avionics system knows, they certainly have their share of bugs quite often.
We can log this issue and see if we can come up with a fix for the next relese.
10 Likes
It is very encouraging to see this kind of clinical examination, explanation, and vindication of the OP’s feedback, which reinforces the perception that WT take feedback very seriously and are working diligently to deliver high quality solutions. Thanks for the detailed response.
Somewhat concerning is that these kind of bugs are present in real world avionics. I think I’ll stick to flying in sims from now on
PS. Don’t forget to tell Garmin how to fix their software
2 Likes
Just part of being a pilot! Gotta keep flying, even if the avionics don’t want to. That’s also why pilots crosscheck everything, all the time.
We have a certified active ATP at WT that has quite a few fun stories of completely borked VNAV, or LNAV flipping out, on planes we all take through the skies commercially every day. It’s all software; as such nothing is perfect, even in the land of aviation. There was a particularly fun one on a certain avionics system where using temp comp on the approach would completely break LNAV on the approach, making the plane turn in the opposite direction of turns; that disabled an entire swath of approaches until a new software load.
8 Likes
Can you be kind report steps you did? From dep to arr, what you’ve set to Garmin?
Thnx for info,
I did yesterday next test flight with same dep/arr sequence, no problem I know Slovak FIR ok. In this case all was set to Nxi correctly, again, same fix as last dep and first for arrival procedure. This is strange why this isn’t working in previous situation. Only as reference, LZKZ to LZTT via MARKA fix. Here all ok in this route. One difference is to previous problematic route that NIT is vor station but MARKA is fix. Maybe this is point to what attention need to be set but this is outside of my possibilities…