tkyler

This looks to be fixed in the next hotfix, due our shortly. -tkyler

a hotfix is coming out shortly....I tested a bunch of stars at LROP with NG1605 and have had no issues. the problem was very obvious in code and hence why I think its fixed...but we hope nothing new shows up. -tkyler

several fixes to LNAV coming up in a impending hotfix.....hopefully this one is covered. it did for me just now with NG 1605. -tkyler

In the next hofix, we will be implementing the ability to save company routes; HOWEVER, this will not include the saving of procedures...only the departure and arrival airports and at least one enroute waypoint. This is accurate to the real thing and why we chose to go this way. We will save the coroutes in the same formate we read, that is: *.fpl format. whenever the minimal information is entered to save a route, the RTE page 1 will displaye a '<SAVE ROUTE' option. Routes with a disco in them will not be saved though. -tkyler

think I have this one fixed. I was able to reproduce the soft crash, fix it, and finally entered the ILS without the crash. A good fix! -tkyler

Fixed. Lets hope they don't remove or add a few spaces in the text file -tkyler

Indeed...this is a very rough week schedule wise. "Graduation time!" Family, events, etc. I am about to begin some serious FMS calibration work though, beginning next week....looking to squash bugs and work on missing features and improved LNAV and VNAV. After that, I'll definitely be interested in evaluating the shared copoilot situations. -tkyler

Thx for the report xplana. I am about to enter a phase of very dedicated FMS work and hopefully catch all of these items. I am having to take a week off due to family medical issues and in addition, I have a daughter graduating college/university this weekend. ....and I'm dealing with family most of the week. I am VERY anxious to jump onto the FMS in earnest and bring it to its potential...is is much closer than the gizmo soft crashes would indicate....I just need to fly a lot. Thx again for the reports. -tkyler

We did not get them in this hotfix. A developer is working with a prototype set and if they all pan out, we'll including them in the next hotfix. -tkyler

It is a challenging feature to implement and I want the more common bugs handled first. -tkyler

I think I have this one fixed, I'll have to flight test it though. -tkyler

Hi xplana. Log.txt indicates that maybe X-Plane's ATC system was involved...I'm going to forward the report on to Laminar. tkyler

will check Franz. Perplexing and frustrating..for both of us. Thx for reporting. -tkyler

The route drawing "rules" are a bit complicated. With over a million possible route combinations, we are going to improve the LNAV 'rules' for various situations during a tuning phase. The "bend" is not a bug, its as intended for the moment. It is a "re-intercept" of the leg between the two waypoints, which IS valid for legs over a certain length...though that length is not defined anywhere, but more "common sense" -tkyler

<ERASE is active after an initial route EXEC. ...and you need to 'undo' your changes relative to the active route. If no route is active yet (due to no EXEC), there is nothing to "erase" per se....and the method here is to simply overwrite what you have before. -tkyler

Thanks guys. We have come across just about everything and as mentioned, what works in one set of situations, tend to break down in other siuations in other parts of the world where procedures tend to have different 'patterns'. This is why someone who flies regularly in one part of world thinks the FMS is 'great' whilst someone who choses a part of the world where the procedures are a bit more...um...challenging, see the FMS as buggy. Writing rules to make the FMS smart in all these cases....while not completely the 'bane of my existence', certainly presents challenges...especially since my ability to fly "routes all over the world" would take me some number of months indeed. Boy would I love to believe that....but Jan has proved me (and himself) wrong on a few occasions with our assumptions. With over 300,000 nav points in the database, the combination of what you might encounter is tough to predict sometimes...I am amazed at the combinations I see sometimes. I am firmly of the opinion that evaluating these on case by case and expanding and adding to, the "rules" relative to other rules is the best course....though we clearly have to wait until they are encountered to evaluate them properly. -tkyler

awesome. THX for posting that debug file.....this is what we do with it...analyze the VNAV path. The path should descend after WHHTE and I can see instantly the issue and we can begin working on a fix....though we are focused on soft crash prevention at the moment. -tkyler

interesting. Yea, the FMS is kicking into descent mode during the calculation, which is why the deviation pointer pops up and the CLB page goes blanks (as it thinks the climb phase is over). Will look into this for sure. -tkyler

we have a hotfix coming out soon Tom that will fix several of these. I can tell instantly your issue as its the same as many previous reports and it should be fixed in the next hotfix. -tkyler

Yes, but TNP is part of BOTH the SID transition and the STAR transition....so when these are entered, the FMS has to make a determination..."which one do I keep"? No we have a set of rules for these cases.... but they are 'growing' as we see new situations and this is a new one. In this particular case, TNP associated with the STAR has a restriction, whereas TNP associated with BOACH does not have any restrictions.....and so I'd think the one with the 'restriction' wins....and I will now add this to our "rules" when we encounter duplicate points. Now if BOTH had a restriction, that could get complicated. In such a case, we'd have to look for another rule to apply ...and things get a bit more sticky here in that we may generalize some rule that works for situation A, but not situation B. What happened here is my code chose TNP associated with the SID (with no restriction) when it should have chosen TNP associated wiht the STAR (because the restriction supercedes). This is on my todo list now. -tkyler

IT should Tom. this is why we need guys like you, nobody ever thought to try and delete a coroute. -tkyler

THX for this. The OAT temperature doesn't use a slash for its entry and that's what my code is choking on. I did test for "Characters", I simply never tried a slash Fixed -tkyler

I couldn't say for sure without a debug output (IXEG_debug.txt). The debug output (not GizmoLog.txt) contains all the route info that I use for route analysis. If you can repeat the error, pause the sim and generate the output (CDU key " . . . . ") then I can analyze the route "step by step". -tkyler

It was your post I quoted.... but I did not mean to imply you were the one punching...my post just kind of morphed into that; however, I have never taken anything you've said as punching at all, I quite view your comments are accurate and constructive, definitley noted! -tkyler

This is definitely one of the areas I was on the fence about. I have wavered back and forth over this, and totally see your point. I'll shed some light on why I went the other way. When I would get a description from Jan about how the FMS behaved....I would assess the workload to implement. I could "block off that feature", toss out some INVALID message" to the user when they tried it....and be done with it. NO gizmo crashes risked, etc. The problem was, that IF we wanted to implemented such a feature in the future, then it had to be wired into existing functionality....and the wiring generally proved to be extensive enough that you just could not leave the feature hanging or effectively block it off....it was either, "put it in now, or risk too much effort adding (motivational problems) it in". So, we really wanted to make this thing as real as we could....and so we just had to say, "lets go for it"....and we did that in so many areas, we just couldn't test all the permutations resulting from the extra options and functionality. THIS is what I refer to as the "rite of passage" or "pain of childbirth". ...and why I say this couldn't go any other way. IF we want a super accurate FMS, then we just have to put it out there, see what users do that we did not, and fix it. Take the punches....and one day, the bruises will heal and we'll have this wonderful thing we envisioned years ago...and it will be good. So keep punching, we'll keep fixing and get there.....but its Sunday, no fixing today Family time. -tkyler