cwjohan

Just tried navigating in the Cessna C172SP G500 and had almost zero success navigating from CYVR Rwy 26L to CZBB Rwy 31 RNAV approach. Four main problems: 1.) It can track the heading via the HDG bug but it is out of alignment by maybe 100 degrees. 2.) The S-Tec Like autopilot wasn't tracking waypoints in NAV mode. Going direct to the first waypoint of the approach didn't work at all on the first try. On the second try it did, but then messed up going to the second waypoint in the approach -- went the opposite direction instead. 3.) The G500 flight plan panel wasn't showing the approach part of the flight plan. Behaves a lot like the CRS is wrong. 4.) In the log.txt one can see a bizillion messages resembling "2026-02-24 20:52:59 OpenGPWS[png.c:70]: Cannot open file F:\X-Plane 12\Resources\bitmaps\Earth Orbit Textures\+40-240-nrm.png: No such file or directory" from OpenGPWS. So, there are some complications here, since there is a Laminar GNS 530 nav unit, a Laminar S-Tec Like autopilot, and a G500 that need to integrate, but it seems they are not sharing data or are sharing incorrectly. Does navigation with this setup work for anyone? The second log.txt below is "the second try" flight, which involved exiting X-Plane 12 and restarting again at CYVR. Ended up landing at a different airport than my original destination of CZBB. UPDATE: Disabled TDS GTN 750Xi plugin before flying the C172. Re-testing as above, got the same results. It didn't help. Log.txt Log.txt

I'm using the G500 with the GFC 500 autopilot, which can output autopilot state data to the G500. There is no remote FMA in the PAE A36 Glass Avionics version, so I'm stuck with no ready display of autopilot/navigation state in the vicinity of the G500 PFD. I bet every user of this aircraft (and perhaps others) would appreciate the ability to see the "Scorecard" data. What would persuade you to improve the G500 in this manner, Cameron?

The G500 SYSTEM SETUP page has a PFD OPTIONS section, but does not include NAV STATUS - STYLE 1/STYLE 2 options. Seems like a huge omission not to have it. and it can be found in the real-life G500 Pilots Guide section 3.4.1. Thus, it seems quite incorrect to say that the G500 doesn't have that feature. It simply is not implemented by RealSimGear as far as I can tell. But, surely, it should be implemented. FAA regulations require the navigation status to be displayed in line of sight of the PFD. It seems unreasonable to force a buyer of expensive glass avionics to install a clunky remote FMA unit. How can we get this NAV STATUS option implemented (sometimes called the "Scorecard")? I have seen an instance of a user of a real-life G500 state that he had the same option missing, but took it to the dealer who installed the option in a few minutes with an "option card" or something like that.

Not helpful. What is the "non-default INI"? What is different in it?

I found that x-aviation.xpl was quarantined by my anti-virus, as you suspected. I have added it to an exception list. Also, gizmodo64 was missing, although I had told the SR22 Entegra installer to keep it since I also have the CL650. So, I re-ran the CL650 installer to install gizmo64. Now, I have both plugins and everything works OK that I have checked so far. Thanks for the quick reply, Cameron.

I'm having a very similar problem with the SR22TN Entegra/SR22TN_AVIDYNE.acf version 2.0.4 downloaded and installed today. Switches don't work. No battery power. Aircraft options panel pops up but numerous options are frozen. It passed license verification (I think): 2025-01-09 23:59:44 SR22TN[ts_killer_instincts.cpp:387]: Aircraft UUID Match Check [PASSED] 2025-01-09 23:59:44 SR22TN[Main.cpp:421]: RA 2025-01-09 23:59:44 SR22TN[Main.cpp:424]: XPLMEnable Complete - 31761 I disabled, using xOrganizer, a bunch of minor plugins that I don't use much: Little Xpconnect, xPilot, Living Scenery Technology, Better Pushback. Plugins still enabled: X-Aviation, XJet, SAM, XPPython3, Traffic Global, AviTab, RealityXP GTN, XChecklist, Navigraph, Airfoillabs Updater. Numerous GroundTraffic for various airports. Log.txt

Thank you, Cameron, for spotting that problem. I didn't see it when I looked for problems in the log.txt file. So, I added the X-Aviation.xpl file to the antivirus real-time-scanning exceptions list. Now it works fine. Problem resolved. Others might have this same issue.

I have this problem too. And cannot pop up the load_manager or the main_menu though they are mapped to Ctrl-Ins and Ctrl-Del respectively. I had the key initially already in the Electric Master switch, but I clicked it and it disappeared. Not hovering anywhere that I can see. X-Plane menus don't display any DA40NG specific stuff. No activation login was displayed on first start. Aircraft behaving like no battery power to PFD or MFD. However, turning Electric Master switch to ON with mouse, I can hear avionics fans running. Turning the Electric Master to Start with the mouse results in no starter sound or prop rotation. I can start the engine with the Flight > Start engines to running menu option. But PFD and MFD don't power up. ESS BUS is OFF. With engines running, switching the Engine Master OFF does not kill the engine, nor does switching the Electric Master to OFF. Switching fuel to OFF also does not kill the engine. Lowering the flaps lever does not lower the flaps. The throttle does modify engine power. Re-install didn't help. Download aircraft and art didn't help. Loading another aircraft first didn't help. Log.txt

With version 1.8, I got this "AP HOLDING RWD", which I presume means "Autopilot holding right wing down" on takeoff. This is a significant aileron mistrim condition. Could that also happen because I am pushing the right rudder pedal while taking off, after turning on the AP? I don't recall seeing the message display in previous versions. More likely, this merely is indicating that the aileron trim was far from neutral at takeoff? In the attached snapshot, I can see the aileron trim far off neutral. Simply adjusting the trim would clear the CAS message -- correct? The attached log file has an awful lot of error messages in it. Maybe some are from the CL650. The snapshot and the log file are from two different dates, but the CAS message was the same in both. Log_ap_hld_rwd.txt

Another link to the Hot Start discord server, please? What is the name of the server? Cheers.

With version 1.6.1 and a new airframe, restoring a saved state in the Airframe Manager, I get a crash to desktop very early on after the restore. The saved state was a ready to taxi situation at KDEN created from version 1.6.1 (not an old version). I start up at KDEN and fix a few restore errors (like GEN1 OFF). Within 1 minute, it crashes. In one case, the crash was within the first three seconds (let's say instantaneous). All I'm doing is looking around the cockpit for anything else that needs fixing to really be ready to taxi. In the Airframe Manager: 1.) I click the saved state name (KDEN-KASE taxi) 2.) I leave "Restore Position and Trajectory" ticked 3.) I click ">>>>> FLY! <<<<<" 4.) I click ">> Confirm? <<" The second attachment below (the instantaneous crash) contains a backtrace, which ought to be helpful. Log_ctd_2022_06_29_a.txt Log_ctd_2022_06_29_b.txt

This happened to me, but I found that I could regain control of the power levers. There is a popup that appears briefly after turning off the ATS and trying to move the power levers. One must position the levers on the Bravo so that in that popup the two oval shapes are lit (solid white). After that, the power levers in the sim track the position of the power levers on the Bravo. I presume this is some sort of sim workaround to get the power levers into the position where they would be in real life.

I tested the above procedure today (without invoking VS or setting descent rate) and it worked fine. I waited until the glideslope intercept altituded was reached before pressing APPR.

I guess it's a VOR approach because HIXOV is PSP104/10.2 and TEVUC is TRM272/10.7. I hadn't noticed that on the approach chart.

If I recall correctly, I had the the altitude set for 4000 ft as the RNAV (RNP) Y approach chart indicates for TEVUC. After passing TEVUC, I probably was too slow to reduce the constraint to 2900 ft. Well before JISOP, I reduced the selected altitude to 2900 ft as indicated by the approach chart as the glideslope intercept altitude. I immediately pressed VS and set a high descent rate to try to get down to 2900 ft before JISOP. Shortly after pressing VS, I also pressed APPR to arm the glideslope capture, which never happened since the actual altitude never got below the red glideslope dot. So, my actions probably prevented the glideslope capture from happening. However, I wasn't actually asking if I did the correct thing -- only what the correct procedure actually is. So, if I understand What Pils said above, the procedure for an RNAV (RNP) approach is: Fly this procedure with FMS1 or FMS2 selected as the navigation source. Before TOD, select altitude setting to glideslope intercept altitude or altitude assigned by ATC, since this acts as a constraint on descent, Press VNAV to engage VNAV mode Optionally, press VS and set a descent rate. VNAV mode will respect the altitude constraints (and optionally speed settings) in the flight plan. Probably not needed. Before the glideslope intercept, press APPR to arm VGP, the synthetic (computed) glideslope or glidepath. When the glideslope is intercepted, VGP will activate and the aircraft will descend along that path. Once VGP activates, the altitude constraint indicated by the selected altitude will be ignored. Cheers and thanks for the feedback. I will try this procedure now and see how well it works.