cwjohan

In an IFR flight from KBUR to KLAS at 18000 ft (see flight plan below), I got a CTD 49 nm out of KLAS. About six seconds before the CTD, there was a brief pause. Then about 3 seconds later another brief pause. And then the CTD. These happened while I had the PFD popped up. I had scanned for alerts and error conditions only moments before this. All flight parameters were OK. Vertical navigation was enabled, but there were several waypoints that didn't have any altitude constraints entered. I may have been approaching one of those just before the CTD. Littlenavmap was running at the same time as X-Plane 11.26r2. Real weather, SMP 4.6 + RWC. No ortho at this location, but some Arizona ortho was far over the horizon. Custom Scenery/Arizona_2015_1m/Earth nav data/+30-120/+36-115.dsf (1278282 tris) possibly had just loaded, according to log.txt. Perhaps 20 minutes before the CTD, I had taken some external snapshots. The last of those snapshots is included below (VNV had not yet been pressed). Frame rate just before the pauses and CTD was around 39. Log.txt KBURKLAS.fms

After takeoff and turning on the autopilot, it seems necessary to orient the TBM 900 to fly toward the active flight plan leg before pushing the NAV button -- either manually (CWS?) or by going into HDG mode. Otherwise, the aircraft will fly in circles. I've also observed this when the autopilot or G1000 switches automatically from GPS to LOC 1. In most cases, the aircraft will start flying circles even though NAV was on. I've observed NAV turning off at this point. Shouldn't happen, right? Even after turning NAV back on, the aircraft does not home in on the locator. The pilot must manually orient the aircraft to fly toward the locator beam, otherwise they end up going in circles. 1.) I realize that this could be a "works as designed" issue, but are the autopilots on real aircraft actually that fussy? Many, if not most, of my X-Plane aircraft seem less fussy and will home in on the active leg if heading in approximately the right direction, which is more how I would expect a real autopilot to work. 2.) This circling business seems illogical. When turning on the autopilot, shouldn't the autopilot maintain the current heading, bank, and pitch? Then, after one presses NAV but the heading is not sufficiently in the direction of the active flight leg, shouldn't the aircraft continue to maintain heading, bank, and pitch and not start going in circles? Comments invited from all TBM pilots as well as the developers, thanks. Are others experiencing the same issue? Is this more an issue of how the built-in X-Plane autopilot functionality works or is it something the TBM 900 developers can modify?

Not sure this is entirely relevant, but on your PFD, I don't see any VPATH indication and VNV is not on in the autopilot. To get into VNAV mode with the TBM 900, you need to press the VNV button on the autopilot and reduce your selected altitude below the FAF altitude constraint. You may need to press VNV again to confirm. The VPATH indication on the PFD confirms you are in that mode and a carat (or sideways "v") on the altitude indicator will show your current vertical deviation from the vertical path specified by the altitude constraints in your flight plan.

UPDATE: I've done at least 3 successful flights since my last report of no problems. No CTDs since enlarging the paging files. My current version is 1.0.8. Flight from CYVR to KSEA had no CTD problems.

The bigger paging files solve the problem for the user, but, for developers, the bug remains. If I were to guess what causes it, I would say getting a null pointer from a malloc. Since there's no obvious memory leak, there must be something that grabs a huge chunk of memory all at once -- perhaps a memory block sub-allocator that increases the size of the block grabbed each time by a factor of 2. Perhaps even the C++ vector object does that when you're appending items to it. In my case, before I added the bigger paging files, the crash was occuring when the active waypoint in the flight plan was transitioning from an ordinary waypoint to one that was located in an airway -- something grabs a big chunk of memory at that point? In any case, good luck hunting it down. Cheers!

RESOLVED: Deimos and coolhand reported that creating a 16 GB paging file solved the "CTD in cruise" problem for them. So, in Windows 10. I used the Control Panel | System | Advanced System Options to create a paging file with a minimum size of 16 GB and a maximum size of 20 GB on my D-drive. Previously, Windows 10 had been using a smallish system-managed paging file on my C-drive. Since then, I have successfully made the flight from EDDK to EDDF with no issues other than the braking problem known to exist in TBM 900 v1.0.6. Note that I have been flying this route using level 16 ortho, which may use extra ram and vram. The successful flight was completed without using altitude constraints or vertical navigation. I'll try those tomorrow on the same route, but I don't expect any problem with them since they worked previously on a KSBP - KSBA flight.

Happened again on same flight with TBM 900 v1.0.6. This time, I had no altitude constraints entered. Again, there were no alerts and engine parameters were in normal range. Monitored memory and GPU usage with Task Manager -- didn't see any over usage of RAM, VRAM, or other resources. Also had the brakes not working issue but changed the joystick trigger to "toggle brakes normal" until a fix is available. After a CTD or an engine fire, I find it a lot of work to get the aircraft back into working order. Maintenance bill now is about $2.5 million! Is there a shortcut way to load the aircraft in a normal, undamaged state? Log_tbm_ctd02.txt GizmoLog_tbm_ctd02.txt

Crashed to desktop midway in flight from EDDK to EDDF in TBM900 v1.0.5. Autopilot was under GPS control at 6000 ft. Vertical navigation on the autopilot had not yet been pushed but altitude constraints had been set up for the flight plan waypoints. View was in cockpit, but had just returned from taking two exterior snapshots and one interior snapshot (Alt-R, Shft-Spacebar, Alt-R). The interior snapshot is attached to assist debugging, since it shows there were no alerts and everything seemed to be going nicely. While the aircraft was making a turn from OBOKA to COL, there was a sudden drop in FPS and a second or two later X-Plane crashed to desktop. Windows 10 task manager was running but I neglected to monitor memory usage, so I don't know if this was an out of memory situation. X-Plane version was 11.26r2. Log_tbm_ctd01.txt GizmoLog_tbm_ctd01.txt

Right. Saab 340A, not Q400. Ha ha. Typing without thinking. The Q400 is a twin turboprop that I fly a lot.

Thanks, JGregory, for looking further into this issue. The playing of pump sounds, as indicated in Gizmolog.txt, may not have a direct connection to the runaway pitch trim issue, but they may have a common cause. My FPS are only in the 13 - 17 range, so simulator time and real time may be very different. Also, my single-core CPU is maxed out. SPECULATION: There may be algorithms controlling pitch trim when autopilot is on that are assuming simulator time is approximately equivalent to real time. Timers based on real time may be popping too often with respect to simulator time because too much real time has passed. On the other hand, at least some X-Plane aircraft are leaving all these kinds of autopilot calculations to X-Plane itself and not attempting to modify how it works with plugin code (or Gizmo code). Which approach does the Q400 take -- does the Q400 code try to control the pitch trim when autopilot is on or does it leave it up to X-Plane default autopilot code? Cheers, Craig

Did a couple of flights with no runaway pitch trim problem. But on this flight, had the problem on ILS approach to runway 12 at KOAK. Photo attached shows the elevator full up. The rudder is completely gone Managed land OK without adjusting the trim. Outer flaps ended up full down, but I had them set for just 20°. See video. Approach speed was just under 120 kts. I don't think the trim should have been that high at that speed. GizmoLog.txt Log.txt LES_Saab_340A_1.avi

Thanks, birdy.dma. I will try that. I suspect that causes autopilot to disconnect, though.

JGregory, logs here. Don't see anything useful in them myself. Loading KSAC had some issues, but was flying nowhere near there -- 143 km (89 miles) distant from KSAC. GizmoLog.txt Log.txt

When flying at lower speeds (e.g., during approach phase) with autopilot on I'm seeing the pitch trim go to an extreme high value (nose up). The aircraft noses up and cannot be persuaded to descend. I have to turn off the autopilot and set the pitch to something more reasonable, but doing that while struggling with an out of control aircraft can be quite difficult. When adjusting the pitch trim, one cannot see where the aircraft is going. I do have a couple joystick buttons assigned to pitch trim, so I can use those more conveniently. However, my real question is what can cause the pitch trim to go extreme position like this while flying? Center of gravity? Just flying too slow? I don't have this issue with other aircraft. Also, I don't remember having this issue with an earlier version of the Saab 340A. I have flown the Saab 340 v1.4.1 only twice so far, so I'll keep an eye out as to whether or not this is a consistent problem or intermittent.