cwjohan

I would love to see a study-level Q400, study-level King Air B200, or a study-level PC12, though STMA have said they already are working on a fairly detailed PC12 NG version for XP11.

With v1.1, I observed IGNITION stay set to OFF between startups of X-Plane.

Nope. Just two in my case. Try dry motoring for several minutes to run your battery down below 24 V. Then try a battery start with GENERATOR set to MAIN. See if you see the flickering. Then try recharging your battery in Maintenance Manager.

When the sim is paused, I can go into the Maintenance Manager | Electrics and replace and charge the battery, but it has no effect as measured by the battery tester. If I un-pause the sim, then it appears to work properly. Not sure if this is a bug or a feature.

Oh. I haven't seen that. I've only seen wandering when the approach is activated. Actually, the wandering generally occurred a bit later later when autopilot automatically switches from GPS to LOC 1. However, since TBM 900 v1.1, I haven't seen the problem. The issue you're reporting must be something different. Sorry, I didn't read your problem description carefully. Still, it you want to see if anyone can replicate your reported problem, you could describe the relevant portion of your flight plan and approach procedure you selected. Certainly, it's not happening with every load of an approach procedure.

The flickering PFD and MFD is definitely associated with having a low battery level or dead battery plus having the SOURCE switch set to BATT and the GENERATOR switch set to MAIN. When the GENERATOR switch is moved to OFF, the flickering stops. If the SOURCE switch is moved from BATT to OFF and the GENERATOR switch is left on MAIN, the flickering persists for 5 seconds or so and then stops. Whether one can access Maintenance Manager | Electrics to recharge or replace the battery seems somewhat random. Sometimes I can, sometimes I can't. Quitting X-Plane and then re-starting it and resuming the previous flight seems often to fix the problem of not being able to access Maintenance Manager | Electrics because of "ESS Bus switch not normal". It appears that on startup of the aircraft, it can repair bad states in the .airframe file, perhaps because some values are calculated rather than obtained from the initial state. Is that the case?

The flickering PFD and MFD is definitely associated with having a low battery level or dead battery plus having the SOURCE switch set to BATT and the GENERATOR switch set to MAIN. When the GENERATOR switch is moved to OFF, the flickering stops. If the SOURCE switch is moved from BATT to OFF and the GENERATOR switch is left on MAIN, the flickering persists for 5 seconds or so and then stops. Whether one can access Maintenance Manager | Electrics to recharge or replace the battery seems somewhat random. Sometimes I can, sometimes I can't. Quitting X-Plane and then re-starting it and resuming the previous flight seems often to fix the problem of not being able to access Maintenance Manager | Electrics.

I think version 1.1 has improved this behaviour compared to previous versions. I too had gotten into the habit of having HDG mode ready to take over before activating the approach, since the aircraft often would wander off in some undesirable direction. It now homes in better, at least on the KBUR (ELMOO8) - (CRESO4) KLAS route I was flying. What is your flight plan and the STAR and approach you are using?

If you manually set the IGNITION switch to OFF, it should stay off -- just like the real aircraft, I would think. Certainly, that's what I would prefer, even if the switch should normally be in the AUTO position. I don't want the aircraft code to "help me out" with things like that.

See the link below for some info on this and a workaround: one is to delete the state folder and let the TBM 900 code re-create it. One also could edit the .airframe file in that folder, but the developer would not recommend you do that. The problems seems to result from a battery going bad. Try going to the Mainenance Manager | Electrics page and see if you can replace the battery. That is the easiest option if it will work. If it blocks you from doing that because "ESS Bus switch not normal", please let me know. Good luck!

Deleting the state folder does work initially, thanks, but then one can do something that puts the battery back into a bad state. Still tracking down what the something is. Might be having the IGNITION switch in the ON position. I've discovered that the elec/sw/ess_bus_tie_cover and elec/sw/ess_bus_tied setting was a red herring (i.e., useless) -- it is always set to false and that doesn't appear to cause any problems. Instead, I've found a more promising suspect: the battery settings. When the battery is "bad" and causing the avionics flashing, the settings look like this: elec/batt_charge_fract = 0.000000000000000 elec/bus/0/volts = 0.000000000000000 elec/comp/batt/wear = 1.000000000000000 When the battery settings are reset to more normal values, the bad battery issue goes away and one can view the Maintenance Manager Electrics and Avionics screens, plus the avionics don't flash. elec/batt_charge_fract = 0.999777767935902 elec/bus/0/volts = 26.098259922938105 elec/comp/batt/wear = 0.000004359834887 ------------------------------------------------------------------------------------------------------------------------------ Some rubbish is getting inserted into this message. Please ignore the images below. I can find no way to delete them.

UPDATE: I'm also getting the same "ESS bus not normal" error in XP11.26r2 as I see in XP11.3b2. Additionally, there is the following issue: 1.) When the crash bar is move to UP and the Source switch is OFF, the PFD turns on -- exactly as it should -- not a problem. 2.) When the crash bar is up and the Source switch is moved from OFF to BATT, the PFD and MFD go dark (turn off). 3.) When the crash bar is up and Source is BATT and the Generator switch is moved to MAIN, the PFD and MFD and other avionics start flashing. 4.) A workaround for this problem is to use the GPU as the source. Then the avionics work just fine. Of course, the Generator must be set to MAIN. I think "ESS bus not normal" problem is somehow connected to this problem since I also cannot look at Electrics or Avionics in the Maintenance Manager when I see this problem. bec60d2f85eba99e5ed388bcb34f54b2.airframe Log.txt GizmoLog.txt

I keep re-experiebec60d2f85eba99e5ed388bcb34f54b2.airframencing this problem. Something is always setting elec/sw/ess_bus_tie_cover and elec/sw/ess_bus_tied to false. TBM 900 v1.1 and XP11.3.

When setting the generator to MAIN with battery on, the avionics begain flashing. I've had the above reported issue every time now in XP11.3 and TBM 900 v1.1. Starting with the GPU works OK, though.

I'm seeing this also. The avionics went dark. Though I found that the battery has some juice One can set the generator to MAIN and start up the engine. When the engine gets up enough RPM, the generator provides enough power for the avionics to work again. When the MFD comes back on, the battery doesn't show a lot of amps, as it would if it really needed recharging.

I was able to "fix" the issue by editing the .airframe file in the Output\TBM900\state folder. I changed: elec/sw/ess_bus_tie_cover = false elec/sw/ess_bus_tied = false to elec/sw/ess_bus_tie_cover = true elec/sw/ess_bus_tied = true However, the Maintenance Manager changes it back to the original false values. Re-loading the aircraft again (after having loaded a different aircraft), the Maintenance Manager is now OK. So, obviously, the particular values there didn't matter. May have been an coincidence that it just started working again regardless of those values, or maybe it jogged something that needed jogging. :-)

Not sure you want to hear about XP11.3 bugs yet, but I was testing TBM 900 v1.1 in a flight from KBUR to KLAS (again) with vertical navigation. The vertical navigation mostly worked as expected. However, after landing and powering down I called up the Maintenance Manager and tried to find out the status of the Electrics and Avionics. It wouldn't let me see them because it said "the ESS Bus Switch was not Normal". However, examining the ESS Bus Switch on the breaker panel, it was guarded and in the Normal position. The other Maintenance Manager functions were OK. I was using XP11.3b2. Log.txt GizmoLog.txt

That's an impressive set of fixes! Will give it a try tomorrow.

UPDATE: Finally made the entire trip from KBUR Burbank to KLAS Las Vegas successfully in the TBM 900 with no CTD. I did a few things differently: 1.) Did not use vertical navigation 2.) Removed all plugins except TBM, Gizmo, and the standard X-Plane ones. When trying to activate my approach, I failed to do it in time and overflew the airport, so I had to declare a failed approach and go back to the BLD waypoint and try again. Worked OK the second time. However, this aircraft quite easily goes off the programmed flight path. One has to be ready to use the HDG mode or manual corrections to get back to the current active leg.

Got several like this that look identical, but logged at different times, despite same time stamp. Faulting application name: X-Plane.exe, version: 11.0.26.1, time stamp: 0x5b7cd2a8 Faulting module name: systems.xpl, version: 1.0.0.0, time stamp: 0x5bd3c700 Exception code: 0x40000015 Fault offset: 0x0000000000988c32 Faulting process id: 0x55ac Faulting application start time: 0x01d471a4b0b5bad7 Faulting application path: G:\X-Plane 11\X-Plane.exe Faulting module path: G:\X-Plane 11\Aircraft\X-Aviation\TBM-900\plugins\systems\win_x64\systems.xpl Report Id: 33376e59-4bfe-49c1-a7e5-e1fb65d053c9 Faulting package full name: Faulting package-relative application ID: ---------------------------------------------------------------------- Faulting application name: X-Plane.exe, version: 11.0.26.1, time stamp: 0x5b7cd2a8 Faulting module name: systems.xpl, version: 1.0.0.0, time stamp: 0x5bd3c700 Exception code: 0x40000015 Fault offset: 0x0000000000988c32 Faulting process id: 0x55ac Faulting application start time: 0x01d471a4b0b5bad7 Faulting application path: G:\X-Plane 11\X-Plane.exe Faulting module path: G:\X-Plane 11\Aircraft\X-Aviation\TBM-900\plugins\systems\win_x64\systems.xpl Report Id: 33376e59-4bfe-49c1-a7e5-e1fb65d053c9 Faulting package full name: Faulting package-relative application ID: ----------------------------------------------------------------------------------- Quite a few distributed COM errors where it is difficult to determine what service is failing. For example: The server {1EF75F33-893B-4E8F-9655-C3D602BA4897} did not register with DCOM within the required timeout.

Here's a good discussion of VOR range in X-Plane: https://forums.x-plane.org/index.php?/forums/topic/128843-vorndb-range/ Littlenavmap shows the range for VORs in X-Plane. For KTM (Kathmandu VN) it shows the frequency 113.2 and range 130 nm, which indicates it is a moderately long range VOR. Of course, altitude and a few other factors affect the actual VOR range.

Great minds think alike.

There is a very large number of errors in your log. Many with scenery and various plugins. But probably the errors causing you to have an unflyable aircraft have to do with "damaged" components in your aircraft. You can repair these by going into the repair hangar (2nd menu item from the top on the left edge of your screen). Look at each type of component and repair every one of them. Each repair costs some imaginary money -- don't worry about the cost. This damage may have occurred during hard landings or by running the engine too hot or over safe RPMs, not following recommended procedures, crashes, even crashes caused by bugs. There is another way to start with a clean aircraft: create a new airframe and run the initial tutorial to initialize the panel (a fix is expected for this before too long).

It's OK to fly the stabilized ILS approach on autopilot down to 200 ft, below which one must turn off the autopilot and ensure that YD is off. It's probably best to have gear down and flaps TO below 173 KIAS and the flaps at LDG position as soon as airspeed is reduced to 122 KIAS, which one should achieve before reaching the FAF (final approach fix). Then, go to Idle power or just enough power to let the airspeed reduce to 85 KIAS during descent on the glideslope. Airspeed can safely drop to as low as 65 KIAS (bottom of white zone on speed indicator) just before touchdown with flaps in LDG position and light or no wind. Hopefully, what I am saying here is consistent with what pilotogerson and sdflyer have said and also with the normal procedures for this aircraft. Please correct me if you disagree.

I just had another CTD flying the same KBUR-KLAS route at 18000 most of the way, but VNAV had kicked in and the aircraft had descended to 7000 ft just before waypoint BLD. The CTD occurred a few miles short of BLD. So, the aircraft made it considerably closer to KLAS this time compared to the previous time reported above. I was monitoring CPU, RAM, VRAM, and GPU usage -- nothing out of the ordinary occurred with those around the time of the crash. However, I did get the same two brief pauses again just before the crash. The log file doesn't appear to show anything useful. There was some VNAV misbehavior: VNAV correctly descended from 18000 ft to 12000 ft where it was supposed to. However, another descent was supposed to kick in at CRESO to descend from 12000 ft to 7000 ft before reaching waypoint BLD, but it didn't kick in. I had to use VS to get the aircraft to do the second phase of the descent. As it should, the aircraft leveled off at 7000 ft even though my altimeter was set to 5000 ft -- so, VNAV was working to some degree. Shortly after leveling, the CTD occurred. Log.txt GizmoLog.txt