Muchimi

Ok thanks!

I'm looking at entering a distance/bearing waypoint in my route. In this case, BLD125030 - so bearing 125 from BLD at 30 nm. How do I enter that in the CDU when I build my plan? I can't seem to get it to accept that, and I can't find the reference manual for the FMC that goes over that. The usual Boeing format is FFFFFbbbb/dddd where FFFFF is the fix name, bbbbb is the bearing with or without a decimal point, and ddddd is the distance, also with or without a decimal point. However this may be a later feature of FMCs, not sure about the model in the 733. Thanks!

Another thing that occurred to me is that the VNAV computation is based on XP10, with the XP11 patch of the 733 not being quite out yet which may also account for some of the strange things experience with VNAV profiles running an XP10 version in XP11 (if you're doing that).

For one here very excited to hear the new version is almost here, looking forward to it soon (tm).

I too get this message on heavier zfw even on routes > 350nm (example KSLC-KDEN). I think the primary cause for the unable crz msg is the VNAV computed step climb puts your top of climb after your top of descent, especially if you have a high FL for a shorter route. Because for the life of me I can't see the computed TOC or TOD indicators on either the CDU or the plan map, it's hard to tell (perhaps my learning curve here). I think the message is mostly correct as if you lower the ZFW or change the cost index, it goes away - I suggest you experiment with that. This said, I still think VNAV gets confused sometimes especially if you start making changes mid-flight and use constraints (speed and/or altitude) or have more extreme weights / aggressive elevation changes in your route. However, most of the VNAV issues I have relate to the VNAV descent profile. Then again, I find it's a way for me to use better planning tools and not rely so much on the automated course as the PIC I need to make sure what the computer thinks makes sense, and trust me, being in the computer field, computers usually don't make sense because I programmed them Hope this helps

I have XP 11 so I should wait until 2.0 comes out? soon (tm)?

Update! I have disabled A/V on the whole XP folder and things are back to normal. In fact, disabling A/V altogether on the XP folder seems to give me a slight boost overall in FPS in XP 11 RC2 - about 1 to 2 FPS looks like although this is not very scientific - there is a slight uptick to my FPS logs in similar situations so I take it that the AV really takes a toll on the XP executables and plugin DLLs. What I didn't connect is that I wasn't changing waypoints - just constraints - but I suppose it doesn't matter and any change to the route would cause this. Very, very strange that all this FMC change architecture would bring the whole computer to its knees without necessarily "pegging anything" in terms of performance management monitoring, but I thank you for the explanation as to what causes this. I think the pinned post could be updated to say "if you get ANY FPS issue, try disabling the AV first". Cheers, M

In my world there are no exclusions - just vulnerabilities waiting to be exploited, but I understand - I get way too into this security stuff as I see how many attempts are made daily to exploit holes and it's my profession to make sure there are no holes.

Yes - indeed not a solution especially after what just happened with wannacry and that other thing last week... The answer is never compromise security to fix a software issue but I suppose the risk here is minimal.

Disclaimer: This is under XP11 RC2 and I know the Ixeg 737 is not yet officially supported in that environment, which may be the reason I am having the issue below. I've experienced a few times now and consistently a major frame rate issue only in the IXEG plane when I start placing altitude or speed constraints on legs in the FMC after reaching cruising altitude. I do this fairly often to comply with ATC vectors or flight levels which may deviate from the default approach initially programmed into the FMC on the ground. Taking a simple example, a flight from Salt Lake to Denver. Here's the coroute: KSLC CHE DIRECT FRNCH DIRECT BOENG KDEN During pre-flight, I add the departure SID from KSLC for runway 16R, and add the arrival STAR at KDEN for 16R as well (via TOMS/KAILE3). In this case, approaching TOMS from FRNCH and being directed to FL210, I set an altitude constraint on the waypoint via the entry of /210 on BOENG. The moment the constraint is displayed, my FPS totally tanks from 35-40 to 4-8 almost immediately. The buttons on the FMC become unresponsive the moment the entry is input, and it takes it a very long time (30 seconds or more) to execute (even for the light on the button to come up). The cursor on the EXEC button takes several seconds to change to the hand. Clearly, something's happening as the whole simulation is now a slideshow. What's very odd is when I look at my CPU and GPU graph is my CPU utilization falls to about 10% and my GPU utilization falls to 6%. It looks like nothing is happening at all and I have plenty of horsepower completely unused (which explains the FPS) but not why. Normally I see 100% utilization on the XP thread, and between 60% to 99% utilization on the GPU for a FPS at my QHD resolution of about 35-45. This happens in an outside view or inside view and I've now duplicated this with either an altitude constraint on any waypoint, or a speed constraint, or both, when apply to any portion of the flight plan, when in the air. Works fine on the ground (as far as I can tell) - so changing that before a flight is not causing the issue. Only in-flight. I saw a post on antivirus software having to be disabled on the XP folder (which as an IT professional I find very strange as in this day and age, security should never be relaxed to fix a software or performance issue because of the risks it entails) but this had to do with adding or changing waypoints - which I'm not doing here - I'm only placing a constraint which only impacts the VNAV component. I haven't tried disabling A/V on XP but will (very reluctantly). I've also been able to reproduce on other flight plans and the performance issue is almost instant when a speed or vertical constraint is added in flight on any existing waypoint although I've only attempted to set speed and altitude constraints on the approach, so slower speed or lower altitudes. This may be just my setup, the fact I'm running this plane in XP11 RC2, but it's done that before the RC2 update and I've been able to reproduce consistently to the point I now stay away from any VNAV changes and just don't use VNAV for approach descent control. There's nothing I can do when the FMC starts to act up until I quit the flight. Restarting the flight returns the normal FPS. Hopefully one of the gurus here can help me explain what I'm doing wrong. My addons are X-Enviro and World Traffic, I also have flywithLua and xassign, and ezpushback. Disabling those does not fix the issue (looks to be completely unrelated). I also have the EADT 738 and the add-on FMC for that and it doesn't cause that issue, only the IXEG FMC so far. Running Windows 10 x64, 16Gb memory @3.2GHz, Ryzen 1800X @4GHz, and a 1080 TI 11Gb card with a slight overclock, current Nvidia drivers, current WIndows patches and current XP RC2 as published on Steam. Thanks!