tkyler

create a folder called "coroutes" inside the IXEG folder. Page 12 of the "interface guide" in the documents folder describes more detail on using the coroutes feature -tkyler

Hello again. I'd like to give another update. During our investigation into updating our NavData to the XP1100 format, it became apparent that this must be the way to go for long-term future compatibility and more reliable route calculations, including holds, but would require a significant rewrite of the FMS base architecture to do so. So over the last 4 weeks, we have done exactly that. We now have the beginnings of a 2nd FMS running in parallel with... but independently of.... our original FMS. We are running 'newFMS' on CDU1 and 'oldFMS' on CDU2. We will NOT be simulating dual FMCs though. This old/new arrangement only exists so we can compare the new with the old while developing the new. It is much like building a new bridge alongside an old bridge...and when the new one is ready, we will remove the old. Much of the challenges we have faced with regards to drawing routes / vnav have been related to the limited nature of the navData format we have used since we began the project. Moving to a format which have been designed expressly for "navigation processing" will go a long way towards easing our algorithm development. The image below shows the two CDUs, both on the "IDENT" page, but clearly displaying differing data as they use differing algorithms/databases....and for those curious, the pilot CDU displays 'odd' formatting simply because we were testing our new display drawing code. We are very excited moving to this new XP1100 format. We have, in 4 weeks, accomplished what took us over 24 months to accomplish originally. Of course we have the benefit of experience, but the elegance and efficiency of the new navData format and architecture allow us to focus on the FMS functionality by orders of magnitude more than before. With the new infrastructure complete, we will begin working on the route editing. The current navData set only supports about 8 different waypoint types. Arcs are not supported, as is common in today's RNAV procedures, but the new format contains all path/terminator types typical in today's procedures. As usual, we thank you for any patience you have managed to muster as we work to improve the IXEG 733. P.S. Jan and myself will be at Flight Sim Expo in Orlando, FL/USA in a few weeks if anyone wants to talk shop. -Tom Kyler

Hello All. This post will be locked as its only intended for public statement. While many people are aware of the IXEG Development status, many others will not and so this post is intended to provide clarifying information. For a while now, IXEG development has sat relatively idle. The reasons for this are multiple and have been stated in other forums; however, two significant factors contributing to that idleness have since wained and IXEG are looking at how to best move forward with IXEG updates again. There are two areas we are looking at for updates, 3D cabin/doors/animations and the FMS. Regarding the FMS, IXEG are looking at transitioning to the XP1100 Navdata format, which is derived from the ARINC 424 standard. Moving to this dataset format would yield increased accuracy in the representation of procedures and more practical data with which to improve LNAV / VNAV / performance caclulations. If it turns out that porting our code to the new XP1100 format is too cumbersome in the short term, then we will seek to patch what we have now and transition at a later time. The important thing is that IXEG are moving again to improve the FMS. Regarding the 3D, this will be a bit more of a undertaking. The development tools IXEG used for 3D development are nearly fully deprecated and there has been a major transition to newer tools and methods. This necessitates IXEG reconfigure our source material to the new formats and we have a LOT of 3D material to translate. This means that the 3D updates will be longer in coming than the FMS updates. Once the 3D is ported to the new tools though, any updates we implement thereafter would come much quicker, simliar to what was done shortly after our release for those that recall. We apologize for the idle time and appreciate all our customers and any patience you've exercised. We are sincerely committed to making the most immersive and accurate simulation of this aircraft as we can and will continue to push towards that goal, no matter where its end may be. -Tom Kyler

That's pretty cool. For the record, I am finally back to working in the FMS, including adding the holds. I'm in the process of porting over to the ARINC 424 / XP1100 nav-data format, which should make things go much smoother for holds...accurate routes / entry....just about everything route related. But thanks for this script...it will be a bit before the holds features get distributed! -tkyler

I feel ya.....you just hit on one of my biggest pet-peeves. That's why my posts tend to be a bit lengthy....a readers mind forms all sorts of questions as it peruses sentences and a lot of folks who write instructions don't address those derived internal questions, leaving more questions to the end user and the lost time to "experiment and test" to get those answers and the ensuing frustration. That was the impetus behind my statement above that communication is a finicky thing....and good comms quite rare IMO. Regarding all the other little things that you are trying to learn with frustration....all I can say is that I know how you feel. While some areas of learning go easy, still many many do not and for myself at least, I have to chalk this stuff up to the pains of 'learning process'. So...regarding the scenery, did you ever get it going? If not, then post the X-Plane log file (should be in the root X-Plane folder) and there are several experienced folks here who might be able to help out. -TomK

Hi Michael, Well I have a confession. I am more like you than you know. I too got interested in "airliner" type flying a while back and even though I'm programming it, I haven't fully mastered it, I still have a lot to learn. What I have learned though during my research of FMC / CDU operation, is: 1) you'd be surprised how many people aren't exactly sure how things work when recalling it from memory and 2) there are indeed small deltas to how the FMC operates between software version and some folks never quite get to see the alternative operation and so get quite dogmatic on how its supposed to work, when in reality, there are variations. I have two very comprehensive FMC manuals and they simply do not give the 'minimum criteria' for the EXEC lit to be lit....at least not that I have been able to find. All examples given in these references have you to press the EXEC key while some waypoints are loaded. So...that being said, I think you have indeed found a bug in the tutorial document. I can only guess that we might have taken a screenshot of the PERF INIT page while some waypoints were loaded and we just didn't catch it. Philosophically, I see no reason the EXEC light couldn't light up after entering some PERF INIT data without a route (at least 1 waypoint), after all, its just a way to tell the FMC "do some calculations now"....and with only PERF INIT data entered, any calculations without the route would be minimal....there are a few, but nothing that alters the flight path of the aircraft. One of my (quite official) FMC texts uses the phraseology, It could be argued that PERF DATA without a waypoint cannot be a flight, and therefore is not a flight plan....nor is PERF DATA only a guideance mode or part of the navigation database. I think this was the logic I used when programming it originally. If you have at least one waypoint (from the navigation database), then you have a minimal flight and that's when you get the EXEC light (after ACTIVATION). More confusing to me still is the term ACTIVATE. For example, below is some text from my rather official FMC manual I have. The above says that entries have been activated by pressing the lighted EXEC key; however, we all know that before hitting EXEC for the first time, there are the words ACTIVATE on LSK 6R...which must be pressed before EXEC. So.... if, according the manufacturers own manual, 'activated' results from pressing the lighted EXEC key, what the heck are we activating when we press ACTIVATE? I tell ya, communication is a finicky thing! Anyhow, thanks for catching that, we'll make the appropriate updates and I hope you don't get too discouraged. Learning an airliner and the ins and outs is daunting and I myself have a long way to go, usually I only undestand one thing at a time and right now, its holds! Thx again, TomK

Hi Michael, thanks for purchasing. I did the programming for the FMC and will try and answer your questions. Mike Ray's book was a effort separate from the IXEG development, so I can only surmise here as I have not gone through it myself fully. Mike's book contains some good info that specifically relates to the particulars of X-Plane and our simulation and so the "IXEG" part of that title has some validity; but in doing so, also gives the impression that it should coincide with our simulation behavior 100%, so I understand your perspective. Could you please provide the title of the tutorials, any version numbers if applicable... and the page numbers that you are following and I will take a look and see. I can say that the minimum requirements to get the EXEC light to light up in our sim is the presence of at least one waypoint....and then hitting the ACTIVATE button from the LEGS or RTE page. Once the ACTIVATE button has been pressed and the EXEC button pressed, then the route with be 'EXECUTED' (and the route on the EFIS will be shown in magenta). Any change to the route or weights after that point will cause the EXEC light to illuminate. In reality, there are many versions of software that the FMC uses and it may be that one version will illuminate the EXEC light once weight data is entered while another does not....I couldn't say without looking at the software version history of the real FMC, which I don't have handy. IXEG doesn't claim to implement any specific version. The FMC does have some unimplemented features (holds for example) and shortcomings with regards to the VNAV calculations, moreso when edits are made while in-the-air, but is robust in quite a few areas. We support two data sets, Navigraph and Aerosoft, and some aspects of the Navigraph data encodings are slightly different and have caused me difficulties in trying to support them both, particularly with STARs and SIDS that have runway transitions. If you have runways entered before entering SID/STARs ,then the behavior tends to be a bit more stable. Now I have been in contact with Navigraph as recently as this past weekend and they are working to alter the data so that it contains more resolution with regards to runway transitions. I believe this will allow me to stabilize the routes and editing appreciably. The plan is to implement the the new XP11 ARINC 424 formats for FMC data, which will give the most accurate routing IMO. I have begun writing code to work with this data, but it is not a fast process and I certainly can't give an estimate as to when it would be deployed. Unfortunately, I have been side-tracked for the past 3 years in a rather busy endeavor, but am happy to report that I am working on it again and very much looking into enhancing the IXEG FMC. -Tom Kyler

Try restarting the sim and select the 737 first. have you restarted the sim since you first loaded/activated it after purchasing

Can't say as I have ever heard that one Josh. Are you able to move the throttles with the mouse?

Hey guys, I don't mind repeating this in a few forums, probably better to have it in more locations. The quick and dirty is that we took @ 6 years to get the IXEG to minimum release....and in the last year before release, things were difficult and we were unsure when we would make it because the team members still have to pay bills and do their other jobs. As it stands, I got involved in a space startup about 9 months before the 733 came out. I managed to 'stall' my participation in that startup for about 9 months and worked solely on the 733 with no income, living on savings during that time to get the 733 out. Wtihin 3 months of the release of the 733, the startup was in full swing and I was the prime designer for our deliverables to NASA. There was a lot riding on the line, many big groups involved, NASA, ESA, Airbus, Boeing, etc....and I could not back out. Because this project was deadline based, and i was already behind, I've been working at it solid for about 2 years to meet the deliverables...which I recently completed just last week by handing over our hardware to head to the ISS on SpX-15 here in about a month....which is why you've seen two whole posts in as many days from me as I can finally take a breath. My participation in this startup is relegated to this "deliverable phase", by my own volition as my passion is flight simulations.....and while I have loose ends to pick up....documentations and such, I am getting poised to get back into XP dev work. I will say, that the release of XP11 also contriubted to some of the 'wait and see'. It should not be hard to tell from the work we put into the 733 that we are passionate about the small details and its painfully clear to the team the features that are missings...and the good news is that we can't let that go, even if it SEEMS that way due to some lack of activity. I know Morten, Nils and I have been in XP Dev work for oh....maybe 14+ years? We very much appreciate you guys cheering for us and your support and while I apologize for this pause, you can be sure that the 733 will surge ahead in features. -tkyler

I'm just now reading this and as a IXEG member and mod here, I have permissions to respond and will. Especially since I'm the one who programmed much of the features Shobhan is lamenting and also the one who has not worked on it in some time. First off, Shobhan complaints seem to be 100% focused on the FMC and indeed that is plausible enough as it it centric to airline operations and a big appeal for airliner sim enthusiasts. But there are also other aspects of a airliner simulation to consider that others find equally important as well and worthy of value. Other products, while having a more complete FMC implementation, might not have as good of visual or aural fidelity....and who's to say that "immersion of FMC accuracy" is more important to simmer A or B than "immersion of visual accuracy", or "immersion of aural accuracy", i.e. I myself enjoy the cockpit immersion, visual and aural more than the FMC usage. I know this is not the case for you here Shobahn. In the end, we want it all to be accurate no doubt. A thorough FMC with a cartoony or disproportionate 3D looking airplane is very disappointing to myself......BUT....I also know the FMC is the centerpiece for most customers and worth the discussion. At the end of the day, Shobahn is entitled to his opinion and I fully respect that....what I don't respect is his calling us lazy. Shobahn doesn't know me, Jan, Nils and Morten from Adam. He doesn't know my wife, my daughters, their trials and tribulations, my brothers, parents and all the things in our worlds that will be important and relevant long after X-Plane is gone from our worlds and sometimes there are things that need tending to at critical times in life that have no other options. Its just the way things can be in life. Now I certainly would not call Shobahn lazy because I don't know him, nor will I call him ignorant....I will say he's made some ignorant statements here in this forum though. IXEG is made up of very very good and talented individuals....so good that each is in demand and always candidates for promotions in their own professions and they honor those committments they made there before IXEG. I also realize there are committments to customers, especially when money changes hands, and I will continue to honor those over time as best I can. The whole team have a long history of longevity and committment to X-Plane. I myself am disappointed at the timing of updates too, but things are what they are for the moment. The alternative was to what? say, "well we won't make the 733 100% accurate for some years and some folks will be upset one day....so lets just not do it at all?" I do not subscribe to that strategy as i've learned that any good thing takes time and you have to start somewhere and always keep moving.... and listening to folks like Shobahn voice their criticisms and opinions along the way come with the territory. If things don't move at a pace to satisfy all, then thats just the way it is. In the meantime, Shobahns comments are very much noted and understood... I even agree with about 85% of them.... and myself, being the prime author behind the FMC....will return to working on it and improving it further quite soon enough. My situation is well documented elsewhere. If nothing else, IXEG have demonstrated tenacity and committment to this project over many years and it will not languish as is. If there's one group I trust to keep moving and improving the 733, even in the midst of the occasional update draughts, its Jan, Nils and Morten! -tkyler

Thank you for reporting. Changing the route during descents does indeed cause some issues...some of which are due to differences to the way Navigraph and Aerosoft encode some routes differently. We are working on 'normalizing' the data between the two, such that we have a common format to improve the VNAV performance when changing routes mid-flight. We appreciate your patience and sorry for the inconvenience. -tkyler

Holds have not been implemented yet. VNAV calculations can be problematic, especially when route modes are EXEC during descents, and we have resumed work on improving these calcs. LNAV is relatively solid statistically, but there are some combinations of procedures that can rear their ugly head. Supporting two datasets, Navigraph/Aerosoft has proven challenging due to the fact that Aerosfot uses "Runway Transition" data types and Navigraph does not...and I have found in many cases that problem routes are due to these difference. We are looking into our algorithms to see if we can hide the difference to the end user. It would have been immensely easier if we'd have just stuck with one dataset....oh well My current focus is on improving the FMS all around. -tkyler

Hi John, I'd have to see the entire route you entered, including perf data to be able to "trace" the routing in code. What I would recommend is right after you EXEC a route, use the STEP function to step through the route and if you see these double lines, then pause the sim and save the file, IXEG_FMS_debug.txt, which will be in the IXEG folder. This file is generatred every time you hit EXEC, so you want to duplicate it when you see the error, less you hit the EXEC button again and lose the data that generated the anomaly. Then you can post that file here and I can examine the data and see whats what. Tom

Glad you like it Wayne, there are some known issues but its about to get a bit more accurate....at which point I'll issue a patch and also update the documents. Regarding going into reverse....some folks say you need to put the condition levers slightly above taxi......but I have no idea why that would work Generally you use the keyboard to toggle into "reverse" (and the yellow light on the panel will light up)....then you move your joystick throttle as normal to go in to reverse. If the reverse light IS lit up and you still have that problem, then definitely some common theme going on with some hardware I have to figure out. -tkyler

Got this one fixed....this is a nav-data problem. I'll post an explanation later with diagrams as I find it a bit interesting to demonstrate some of the challenges here. The solution, is to edit the XML data file, particularly the transition in question. You will note in the latest data set (Navigraph 1706?), there are 5 waypoints in the transition, the last waypoint being "LB484". You need to delete from the XML file the waypoint BEFORE this waypoint, and change the Waypoint ID of LB484 to '4'. This will allow the procedure to load. More to follow. -tkyler

Thanks for testing TomS. This looks to be an "ambiguous intersection" calculation....which I'll have to talk to Jan about how to handle gracefully. We labor under the assumption that the waypoint nav data sequence is "sane" and in some cases it is not....and in some instances, we cannot calculate an intersection (due to diverging paths). This is "hit and miss". LSZH, for example, has this problem with newer data where it did not with older data. Its like being in Texas and saying, "head due south till you get to New York City" The numbers just won't add up...but we'll come up with some message. -tkyler

Got this one fixed Paul. Thx for reporting. A discrepancy in the navigraph vs original aerosoft entries brought this one to light, but it was clearly an omission of a much needed line of code in a very specific "IF path". -tkyler

I noticed that just before I revised my post The version that is. I'll try to reproduce with the Navigraph set. Thx. Hope I can recreate, this is a very elusive bug when it rears its head. -tkyler

Hey Paul. What nav data set are you using? Aerosoft or Navigraph? -tkyler

The road map is to get the V11 compatibility version out, which is imminent....then go back over the FMS ...VNAV, holds, etc. While that is ongoing, we are also working on new cabin 3D elements. That is the immediate path. After all that...and the plane is performing well and looking well, then I myself will be interested in some failures type of interaction -tkyler

indeed that is one we have never seen.....if its a quirk in our code, then I'm thinking maybe our code is self-aware and writing itself As Jan said, we're going to do a revamp here in the near future. -tkler

Hi Jens, its a bit of a convoluted circuitry dependent upon multiple inputs...especially when messing about with failures. Standby power is normally sourced from "Transfer bus 1" via a relay that is energized from the DC bus 1. When the transfer bus 1 fails (or DC Bus 1), then this relay relaxes and connects the standby busses to 'Side 2'...specifically the battery bus. You should be able to fail the transfer bus 1 (or DC Bus 1) and the battery bus and have the standby system go down....BUT that won't happen because I just discovered a bug in my code while testing this. It does not affect your scenario however. ...and I have fixed the bug! -tkyler

The above question illustrates the challenge for XA in developing a robust installer. The installers used have to be programmed to handle a wide variety of cases and some unknown number and type of files that may or may not be changed by the IXEG team in the future. This requires some time of fore-thought to determine what will be required by users and ensure those cases get coded into the installer. Bandwidth on this level is quite expensive so just downloading everything every time is not a valid option...so crafting a "smart installer" is where the time is going currently. The payoff will be a robust and quick installer for future updates. This whole transition to V11 has caused a bit of a "traffic jam" in our infrastructure and that's all this is....best to proceed through it cautiously lest we end up missing something obvious. Once past it, we expect a clearer road for updating. -tkyler

Hi Cris, Those have been fixed for the V11 update, which is not too far away. -tkyler