Search the Community
Showing results for tags 'vnav'.
Found 13 results
-
The plane suddenly entered descend mode when I'm climbing. I have to use lvl chg to climb to the cruise altitude. As is shown in the screenshot, I'm hundreds of nautical miles away from destination, but the desc path indicator shows that I'm 7000ft above descend path What happened?
-
FIXED / JUST INCREASE JOYSTICK DEADZONE / PROBLEM APPEARED AFTER X-PLANE UPDATE 11.30 Dear all, I'm trying to fly a route fully on FMC but for some reason VNAV is not engaging (though LNAV is). No error warnings on the flight plan. It's quite continuous, no problems there. Could it be after I updated to X-Plane 11.30? Could it be because I changed a couple of times the destination airport without "hard resetting" (fully reloading) the model? Besides, is there anyway to troubleshoot this, to know why VNAV is not switching on? Thanks in advance for any ideas A.
-
Hey! So I bought the IXEG 737 for X-Plane 11 (v1.2) and I can't get the vnav working. I press the button but nothing happens, even the light doesn't illuminate on the vnav button. Also I have no crz, clb or des speeds in my fmc. Also no t/c or t/d on the nd. Anybosy know how to help? Otherwise it's a spectacular plane.
-
Just did a quick flight from KSDF to KMDW. I programmed an RNAV approach, and this may be the first time I've tried an RNAV approach with the 733. Anyhow, I don't care for VNAV much, so I always fly with LNAV activated, and I control altitude and speed with the MCP. However, during this flight, everytime I crossed a waypoint, the VNAV would turn on, and try to take control. I would then turn it off, and resume MCP control, but at the next waypoint, the VNAV would come on again. I eventually just turned LNAV off, and that stopped VNAV from coming on by itself. Question: If a RNAV approach is selected, does this then force the use of VNAV during the flight? Tim
-
Hi, I know that VNAV has remained untouched by the last update, but just to give devs one more case study for a future update, I'd like to report the following behaviour. Route: LIPZ ROTAR6X.04R ROTAR P11 PUL UN606 ZDA UL607 PETAK PETAK2J.17 LATI CRZ: FL370 CI: 20 ZFW: 46 t FOB: 5.2 t Navdata Aerosoft NavdataPro cycle 1706 Further info in the attached logs. According to the calculated VNAV profile, TOD should be over PETAK, corresponding to an ALT restriction of FL120A. It seems that past FL370 over PETAK a discontinuity in the vertical profile exists as the next waypoint TRN23 is only 5.2 nm far and calculated at FL100. The first time I trusted this profile and it costed me a very long holding to lose the excess altitude (and a lot of fuel). Then to adjust the VNAV profile I had to manually delete the ALT restriction over PETAK and force ALT to FL120 (else it would have been less thus violating the restriction). In this way TOD is correctly moved far enough to descend according to the numbers. It seems that ALT restrictions are the culprits behind VNAV quirks... Hope this helps and thank you for the good job! Cris IXEG_FMS_debug.txt GizmoLog.txt Log.txt
-
I was doing a flight today with the following routing. It was the second time flying this arrival and both times I ran into the exact same problem: KCVG BNGLE4 BNGLE RIKLE WWSHR DORET J584 SLT FQM3 KEWR (ILS04L) I was flying without ATC so I entered a couple of altitude restrictions on the arrival while in flight. The altitudes I used were based on the "Expect" notations on the chart at RACKI (13000) and SWEET (7000). Both altitudes seemed to work fine after pressing EXEC. This arrival has a vector section after SWEET which seemed to work correctly. LNAV and VNAV was still engaged. The problems arose when I tried to go DIRECT to the IAF of KILMA. When I pressed EXEC after moving KILMA to the top of the LEGS page, I received a message "UNABLE CRZ ALTITUDE" and the plane immediately tried to speed up to 290 kts. I had to disable VNAV, adjust the speed manually, and start using V/S to adjust the rest of the descent. X-Plane log and FMS Debug files are attached. Arrival Chart: http://imgur.com/LGMEJFq IXEG_FMS_debug.txt Log.txt
-
Reference: IXEG 737-300 Classic version 1.0.7 X-Plane 10.50rc1 NDP AIRAC 1608 rev 1 Route flown: LEPA MERO2A.MEROS UN853 LUMAS UM976 SOFFY UQ208 MOBLO UZ662 LAMUR Z67 KORED UN871 DITON T163 ZUE T125 ROMIR UN851 KEMAD P605 AGATI.AGATI2K EDDH Departure: 24R Arrival: ILS 23 Effects observed: The VNAV profile proposes a ToD only 70NM from the runway threshold for a descend from FL360: On a second attempt (the one for which I attached the logs), I modified the ALT Constraint for PISAS from 3000A to 3000 (as 3000ft would be the GS interception altitude at PISAS), but this did not change the VNAV profile. The constraints in the Nav Data (at or above) are OK (apart from PISAS), but the computed VNAV path is way higher (and steeper). At one point, the ND even claims the VNAV path to be at negative altitude (saying I'm 16,600ft above VNAV path while flying at FL125): In real life, the ToD would be somewhere shortly before DLE... Log.txt GizmoLog.txt IXEG_FMS_debug.txt
-
RTE (KRDU to KBWI) BEXGO2 LVL THHMP RAVNN6 FL230 ACROW FL210A DFORT 284 / FL180A WALKN 280 / 17000A JAYOH 280 / 12000A ... : At FL230 T/D is calculated after ACROW. ACROW FL210A. Current FL230 and above FL210, not too bad at this point: At ACROW at CRZ altitude FL230 (already changed my altitude to 9000 on MCP to start descending at T/D). Next, DFORT at FL180A, 10NM out: At T/D 508 above. At DFORT 2727 above (V/S 3K): (V/S 4K +) trying to get to VNAV path: At JAYOH leveled out at 18000. "Drag Required". Speed brake out. Engines spooling up to maintain 18000 at 280. Approaching CAPKO, leveled at 17K (7314 above VNAV PTH), should be at 9K. MCP at 3K. ... ... ... NAVEY should be at 6K, leveling at 9K. MCP was set to 3K. From here it is just staying at 9K. MCP is at 3K: If I am doing something wrong, please let me know. If you need additional information, please let me know. If this is already reported, disregard the report. Thank you!
-
Sorry for the title of this post, I didn't find anything more suitable to describe this experience in just a few words. So here's what happend on my last flight from LEMG to LEPA, using this route: LEMG 13 ROLA1H ROLAS UN851 IZA IZA1P LEPA 24L (IAP: ILS Z 24L, MJV transition) Navigation data used: NDP AIRAC 1605 I started descending some 25NM before the calculated T/D using V/S mode (VNAV mode was not used during whole flight, but the FMS was completely set up so it could have been used, even including ISA and wind). Lateral navigation was done using LNAV mode (engaged shortly after TO and maintained for the whole flight until final). Passing waypoint IZANB (first fix of the STAR, comes after the T/D), the LEGS page got "stuck" on that waypoint - i. e. it continued displaying it as the active waypoint. Also the VNAV path indication showed its deviation based on that waypoint, as if the aircraft had never reached it. At the same time however (remeber I was flying with LNAV) the flight director continued tracking perfectly the magenta line to X232 and SABAS without any issue (despite two HDG changes on these segments). Usually when missing a waypoint, LNAV will make you go round in circles until you alter the routing or properly intercept the missed WP. So to me it seems the VNAV part of the FMS and the CDU "lost" the route progress, while the LNAV part of the FMS correctly followed the route - the HSI consequently however did not highlight the waypoint LNAV was flying me to. Maybe this screenshot helps illustrating the situation: Next thing I tried is recovering VNAV and the legs page. Directly after having passed SABAS, I activated MJV (next waypoint after SABAS) by coyping it to LSK1 and EXEC. The legs page was then updated accordingly, however the VNAV deviation was still stuck at IZANB, and the HSI was still not highlighting MJV as active waypoint (however LNAV was not much impressed by this, it tracked the WP anyway): After the aircraft passed MJV and started tracking MJV11 (next waypoint after MJV), without further intervention from my side, the situation recovered: the LEGS page updated automatically to MJV11 the VNAV path deviation shrunk to something plausible (MJV11 has an at or above restriction on it, so the FMS estimation was not visible at that moment - therefore just "plausible", but correct with high probability) HSI shows MJV11 as active waypoint (magenta highlighting) Attached the log files (Gizmo will show you the mandatory soft crash for me having forced a debug output on this, but since it seems like a VNAV/LNAV story, I thought it could be useful...)
-
Hello, VNAV used to calculate TD/TC when entering Arrival STAR/Transition ONLY. 1.04 requires entering landing RUNWAY, otherwise it will not engage VNAV. Is that suppose to be like this? Many thanks
-
I experienced the following when flying LEMD/GCXO with this routing: VTB1S VTB UN10 HIJ UN857 TERTO TERT3L using the ILS Z 30 IAP via TFN, Departure at LEMD RWY 14R, Cruise at FL370. Issue: The DES and the CRZ page show different estimates until ToD: The plausible one is the one from the DES page (but not drawn on the HSI), whereas the one from the CRZ page is further than the destination airport: NB when I took those two screenshots, I was already descending manually, thus N1 being limited to R-CLB instead of CRZ - when reaching the actual ToC, N1 limit switched to CRZ and the CDU switched automatically from the CLB page to the CRZ page, so I assume the aircraft configured correctly for cruise. Plus, the two different ToDs were already displayed at cruise before I started descending. When I noticed the tow different displays (no sooner than already far into cruise), I tried exporting a debug output, which was responded by a Gizmo soft crash: However, a debug file was produced nevertheless (cf. attached IXEG_debug_05.txt).
-
I noticed one thing where I'm not sure if it's a "works as intended": I mostly use LVL CHG in conjunction with N1 for climbing and descending instead of VNAV. This implies that at one point one has to switch between IAS and Mach. Now what I didn't expect: The B733 does this on its own (on the MCP), but not in sync with indications on the FMS CLB page. When climbing with 284 KT IAS (corresponds to a CI of 40), the automatic cut-over to Mach happens at ~FL260+, resulting in a Mach target of 0.70. At the same time, the CLB page still highlights the IAS speed of 284 KT and switches to Mach no sooner than ~FL295 with a Mach target of 0.73 (as indicated after route and perf are entered and EXECed). On descend, a similar behaviour can be noticed: An automatic switch back to KT IAS happens also too early with ~260 KT instead of some 280ish speed as indicated on the DESC page. Now on one hand it seems logical that LVL CHG ignores what is set in the FMS (it's not VNAV after all...), but I couldn't find anything about an automatic switching between IAS and Mach... -
There is still a bug in VNAV, and that bug is that VNAV doesn´t follow the fmc speed and not even the restrictions speed (250knt before 10000ft) after a turnaround. For example, if I land at an airport and then prepar the aircraft for the next flight and then takeoff and activate vnav, the aircraft won´t follow the speed restriction of 250 knt bellow 10000 and will instead accelarate to a huge speed. So what I have to do is to reboot the aircraft in turnaround state. Hope you fix this bug soon, thanks
