WaarEagle

Hmm, that's interesting. Does this happen when Power management mode is left at the default "Optimal performance" or when it's changed to "Prefer maximum performance"?

All of my flights have been in 11.41... the log shows it; but I guess I should have mentioned that at the outset. Have not tried the TBM in any of the betas; but I may make an attempt soon. I agree that X-Plane requires very few driver tweaks. The only settings I change are Vertical Sync, Display Mode, and Power management mode. I'm not convinced that Display and Power management really do that much; but it doesn't hurt anything, so I go ahead and change them to the appropriate mode. I've deactivated unused scenery in the past; then did some bench-marking and found that it made little to no difference in loading times. Now I load everything up at the start. X-Plane is not like FSX or Prepar3d... it only appears to access scenery when you're close to it (which is really nice!).

Okay... let me try to explain. This is somewhat technical so I'm going to to simplify some things (I don't really want to address topics like frame buffers, latency, etc.) and hope I don't misspeak as a result. The reason you are seeing long frames (which is the proper term for a micro-stutter) with all your aircraft is because you are not limiting your frame rate. Without a limit, X-Plane will produce the best frame rate it can based on the complexity of the scenery, graphics settings, type of aircraft, etc. This may be 50 fps at times, it may be 40, it may dip into the low 30s if the scenery gets really complex. Now consider your computer monitor. A standard monitor will have a fixed refresh rate measured in Hertz (Hz - cycles per second). Most mainstream monitors have a refresh rate of 60 Hz - meaning it can deliver a moving image at 60 fps. High-speed gaming monitors can go up to 144 Hz (or even higher) for even better performance capability. Now, to achieve ideal results, the frame rate delivered by the sim and video card needs to be EXACTLY identical to the refresh rate of the monitor... and I mean EXACTLY. If you have a 60 Hz monitor, the ideal frame rate is 60... not 59... not 61! Let's look at one 'second' in the life of an X-Plane flight. Assume that during that second, X-Plane is able to send 45 different images to the video card, producing an fps of 45. The problem is that the monitor is demanding 60 fps because it's not going to slow down just because X-Plane can't keep up. To compensate, the video card is forced to make up for the difference by delivering an identical image multiple times until it gets a new one from X-Plane to send. Any time an image is used more than once, a long frame results... which is perceived as a pause. The more consecutive times an identical image is sent, the longer the pause and the more noticeable it will be. There is also the opposite case. Let's say you have a super computer and X-plane can provide 100 fps to the video card; but the monitor can only accept 60 of them. In this case, some of the images that X-Plane worked so hard to produce are abandoned before they can be fully drawn... this often results in screen-tearing where the top half of the screen is a tiny bit out of sync from the bottom of the screen. This is not usually a major issue because it's nice to have really fast frame rates from the sim and the tearing can be eliminated with Vsync... it's just a slight waste of resources. I'll talk more about Vsync later. Usually, when people complain about frame rates, they are not actually complaining about frame rates! They are really complaining about a lack of consistency in the frame rates (stutters, long frames or micro-stutters, judders, etc.). Sure, if fps dips below around 24, the sim progressively starts to resemble more of a slide-show than a motion picture; but using today's modern hardware, frame rate variability tends to be a more common issue. Let me state an indisputable FACT here: Anyone using a standard 60 Hz monitor that is not achieving a constant 60 fps in X-Plane is NOT getting a perfectly smooth frame rate! Any time the fps is less than the monitor refresh rate, there are going to be long frames (micro-stutters)... it's just simple math. I always get a chuckle when someone claims they are getting a "butter smooth" experience at 35 fps on a standard monitor; because in reality (unless they have a 35 Hz monitor or are using G-Sync/FreeSync or an equivalent technology) it's mathematically impossible... each second, the video card is going to have to compensate for 25 missing images in the form of long frames. If those frames are dispersed uniformly, it will be a lot less noticeable than freezing the scene all at once for 25 consecutive frames (a true stutter); but it will never be truly smooth. One day, the hardware will advance enough to guarantee a consistent 60 fps in our sims regardless of the aircraft and scenery we throw into it; but that day has not yet arrived. For those like me that value a consistent frame rate above just about anything else, we had to come up with a method to conquer the mathematical reality of long frames. The best way is to limit the frame rate provided by the sim using a simple formula: (monitor refresh rate / integer). For a standard 60 Hz monitor, these target frame rates would be 60 (60/1), 30 (60/2), 20 (60/3), 15 (60/4), and so on. What's interesting is that for any rate less than 60, this solution doesn't eliminate long frames (it usually increases them!); but it creates a situation where every frame is the same duration, which guarantees a truly smooth experience. In my situation, I am nowhere close to being able to maintain 60 fps in X-Plane all of the time, so I drop down to the next target (30) which I can sustain in almost every situation. In essence, locking frames at 30 makes every frame a "double" long frame. Is 30 fps perfect? Absolutely not! It's creates a tiny bit of input lag and produces a very subtle choppiness; but for many, the slower but steady visuals are much more immersive than dealing with constantly varying frame rates and random long frames. So if someone decides they want to lock frames in X-Plane, how they do they do it? First of all, they must run X-Plane in full-screen mode! I don't know of any methods that work in a window (I use Nvidia exclusively on Windows... so can't comment on AMD and/or other Operating Systems). Method 1: Go into "Manage 3D settings" in the Nvidia Control Panel - a profile for X-Plane can be found or created on the "Program Settings" tab. From there, the Max Frame Rate variable can be set in the resulting list of options. Method 2: I find limiting frames with Vsync to be smoother and more desirable (your mileage may vary). The primary purpose of Vsync is to reduce screen tearing (where part of the screen gets offset from another part and it looks like the screen has been "torn") when the incoming frame rate exceeds the monitor refresh rate. Although there are different types of Vsync; what I consider a side benefit of using "adaptive" Vsync is that it will also limit your frame rate to the refresh rate of your monitor. So I know what you're thinking... if I have a 60 Hz monitor; but can only achieve 40 fps in the sim, what kind of benefit is that? Fortunately, the video card geniuses at Nvidia also created a Half Refresh Rate Adaptive Vsync that basically "fools" the driver into thinking that your monitor's refresh rate is half of what it really is. For a 60 Hz monitor, the driver thinks it is only 30 Hz and limits frames to 30 fps accordingly. I force Vsync to 1/2 rate using Nvidia Inspector (third-party utility); but I believe it can also be set in the "Manage 3D settings" of Control Panel. Find (or create) the X-Plane profile on the "Program Settings" tab and set Vertical Sync to Adaptive (half refresh rate) in the resulting options. Warning: There is a bug in some driver versions where if you open any other program in full-screen (including watching a video in a full-screen browser window) before starting X-Plane, the 1/2 refresh rate setting may become disabled. In this case, you need to restart Windows to get it to reset (do not shutdown and reboot, you need to actually select the "restart" option to truly refresh the OS environment... look up Windows Fast Startup if you doubt). So why did I spend an afternoon writing a primer on the benefits of locking frame rates and what does it have to do with the TBM? Well, I thought some people might find it helpful ( especially if they've been living with inconsistent frame rates and never knew there was anything that could be done about it). The other reason is that I'm convinced that the slight pauses experienced with the TBM have nothing to do with video output, monitor refresh rates, or anything else I've talked about up until now. X-plane has two different "frame-rates". The one everybody knows about is the rate at which it can render frames and send them to the video card for processing. The second is the internal clock of the simulator that impacts the flight model iterations and the dynamic calculations that are occur "behind the scenes". Based on what I've observed (and tried to illustrate using the performance graphs), the TBM appears to be interrupting the internal clock just enough to create slight stutters in the sim as a whole. The graphics output appears fine... I'm still getting a steady 30 fps; but the motion calculations that govern what image to draw are are being impacted just enough to make it noticeable. Anyway, that's my theory... take it for what it is. Now my hands are getting tired and it's time for a beverage... I hope this was somewhat helpful.

Actually, disabling Vsync was one of the first things I tried when troubleshooting the long frames; but it didn't have much effect, so I didn't mention it. I just ran the identical scenario (middle of nowhere with minimal 3-D objects) without Vsync and averaged 50 fps; but there were still long frames due to the background fluctuations. I understand what your saying; but I don't think it applies in this case. I find it interesting that Goran asked why I prefer to lock at 30 (on a 60 Hz monitor). Is the concept familiar to you or do I need to provide more explanation?

Okay... last test. All plugins disabled except gizmo, scenery is completely default, and positioned at an airport in the middle of Kansas with no 3-D buildings (about as flat and isolated as you can get in the U.S.). I even turned the scenery complexity down to minimal before taking the screenshot. I'm still getting the sawtooth performance curve. Notice that both the screen frame rate and the sim frame rate average 30 (they'd probably be pushing 100 if I disabled vsysnc); but the sim frames are down and up, down and up, etc. - this is what causes the micro-stutters (and no, I do not consider a 2 fps variance "more than acceptable" - that's the whole reason I and a lot of other people limit frames to 30 in the first place). I'm not just talking about the occasional hesitation here and there... it is constant and consistent. All I can figure is there has got to be some rogue process in the TBM that is executing some really heavy duty instructions in a loop (and it even does it when the aircraft is completely powered down). Keep in mind, the TBM has not always acted this way... it was much smoother before the most recent updates. Like I said, I'm not asking for an immediate fix; but I do hope it eventually gets fixed... because it's a problem (the graphs don't lie). Now excuse me while I go put my X-Plane installation back together. Log.txt

I didn't just compare it to the C172, I also compared it to the FF A320 which is every bit as complex (if not more so) than the TBM. Scenery should make no difference unless one is inside a highly complex scenery area; but if it puts that argument to rest, I'll go ahead and clean out my custom scenery folder and report the results in a couple of days.

Log posted as requested. I loaded up a new flight with all plugins removed except Gizmo. Background sim is still very choppy: Log.txt

In addition to my response in another thread, I wanted to post some screenshots comparing the TBM's performance to other aircraft in X-Plane. The first is the lightweight C172, the second is the hard-hitting FF A320, and the third is the TBM. The setup is identical for all 3 aircraft: Same parking spot, same time, same weather, same add-ons, etc. The sim is running full-screen, 1920X1080, with frames locked at 30 using 1/2 refresh rate vsync in the driver. The pinkish orange line is the visual refresh rate, while the darker orange line is the background "simulator" refresh rate. I'm thinking that it's the background processes that are leading to the visual stuttering/jerkiness (even though I'm still maintaining 30 fps on average). As I said in my previous post, I'm not looking for an immediate remedy... just trying to document what appears to be a significant problem (never had it before the versions released this year).

I'm not looking for an immediate solution; but add me to the list of users that noticed the micro-stutters appearing in the last few versions. The TBM was much smoother prior to December of last year... so if you're looking for the cause, look at the more recent changes that have been made. Frame-rates are steady, so it's not because of overloaded hardware; but there is definitely some background process that is giving the TBM a "hitch in its git-along".

I've never had any problems taxiing the TBM. Even before the latest version, it only became really skittish at higher speeds... now it handles well at all speeds.

After making several test flights, I'm 99.9% sure that (in my situation) the conflict is occurring between the TBM and ActiveSky. I tried a flight with World Traffic 3 disabled and experienced a crash within 30 minutes. For the next flight, I re-enabled World Traffic and changed the weather generation from ActiveSky to X-Plane's internal real-world weather. Since then, I have not had any crashes at all. Based on reports from other users, I'm not inclined to believe that the problem is caused exclusively by ActiveSky (since others are experiencing the occasional exception handler fault with xEnviro, FSGRW, XSquawkbox, etc.). Again, my gut tells me that the TBM is not correctly handling certain weather changes initiated by external weather programs... but I'm not sure which parameter (wind, cloud cover, precip?) is the cause. I remember that several builds back, the TBM was crashing consistently for everyone after Laminar made some weather-related code changes in 11.31. That problem has obviously been resolved; but I'm beginning to wonder if this is a very similar issue - except that it only occurs when using external weather generators. To add additional detail, I normally run Activesky on a remote computer. The program communicates with X-Plane over a network using the ASXPConnect plugin. I have NOT disabled the plugin in X-Plane; so the TBM and ASXPConnect module do not appear to conflict unless ActiveSky is "actively" manipulating the weather. I hope this provides some clues on where to start looking to resolve this issue.

Understood. For my part, I'll make some flights without World Traffic running to see if it eliminates the crash. Since I experience the exception handler reset regularly, it may help to pinpoint the conflict. Will report back.

But that log entry appears to be generated by the TBM... are you saying that it's coming from another source?

The TBM's exception handler continues to reset on 1.1.9 (at least it crashed on the taxi out instead of toward the end of the flight this time). It's now been several months and the incompatibility still has not been identified? My gut feeling is that the TBM is either not getting along with external weather apps (ActiveSky, FSGRW, etc.) or World Traffic... but that is really just a guess. On the plus side, really loving the improved ground handling in the latest update. I don't plan on disabling any plugins (since they play nice with every other aircraft except the TBM); but I'm attaching my log for reference. Log.txt

Any progress in identifying what is causing this particular crash (TBM900[except.c:282]: Something reinstalled our exception handler, replaced it with 0000000000000000)? I had it happen again tonight shortly after takeoff using version 1.1.7 and don't see any fix mentioned in the notes for 1.1.8.

I experienced the same... the crash appears to occur when mousing over the sidebar menu. Nothing to see in the log... X-plane crashes so suddenly that no debug info is recorded.

It's not xEnviro... my exception crashes occurred while using ActiveSkyXP on a remote server.

I got this exact same error on a flight this evening: TBM900[except.c:282]: Something reinstalled our exception handler, replaced it with 0000000000000000 The TBM was behaving fine for a full hour of flight time; then without warning, X-Plane crashed to desktop. The square in the Read-only box has nothing to do with anything... it is only there as a reminder that folders cannot be set to Read-Only in Windows (only the files within can). Notice that to the right of Read-only it also says "(Only applies to files in folder)". Getting back to the TBM CTD, these crashes are really starting to get frustrating. I know the aircraft is wonderfully complex; but it seems every new patch introduces a new way to kill the simulator (how thoroughly are these patches being tested before they're unleashed to the public?)

I had the same issues after updating to 1.1.4C. The throttle constantly increased to full. Solved the problem by deleting all files in <X-Plane>\Output\TBM900\flightlog and <X-Plane\Output\TBM900\state. The files will rebuild after restarting a flight with the TBM. This effectively gave me a brand new airplane (complete with introductory tutorials) and the throttle problem was resolved.

Yup... as long as there's little to no crosswind and the pedals don't need to be touched, it lands alright. The video from Grau Adler actually supports my particular complaint -- the no wind landing was okay; but while he's taxiing, he looks down for a second and almost goes off the pavement. That's why the takeoffs in the TBM are worse than the landings, it requires more yaw input to counteract the applied power and the yaw instability on the ground is the problem. In my 33 years of simming, I've seen plenty of flight models tested by real world owners and pilots that handle horribly in a simulator (and unfortunately the TBM appears to be one of them at this point)... actually the TBM handles very well in the air, it's just the ground dynamics above around 20 knots that are so bad. I'm not going to get into a debate either; but you can either listen to Jason Miller (who probably spends a whole lot more time flying his real airplane than the simulated version) or you can listen to the users who know a thing or two about how a simulated aircraft is supposed to roll down a runway (and know how to correctly compensate for P-factor and torque). I'll leave it at that.

Well said! For an aircraft that is perfect in so many ways... the twitchy ground handling sticks out like a sore thumb. The 11.30 beta fixes a lot of the internal ground handling issues in X-Plane; but the TBM still handles very poorly even in the beta. Making a custom yaw curve helps a little (I use a linear curve and set a point for .10 response at .30 travel); but I believe the main issues can only be fixed by tweaking the model. It seems as if the yaw response is delayed -- which leads to over exaggerated control inputs (stability augmentation is not the problem -- I have it turned off). I hope this gets addressed soon.

Gotta agree with Cameron on this... if you weren't prepared to accept possible glitches and troubleshooting, why in the world did you buy the product on the first day of release?!?!? Wait a week to cool down and don't throw away your past investments. I really don't mean to twist the knife; but I haven't had a single CTD since I purchased the TBM 10 minutes after midnight on Saturday. I know you're frustrated; but try to remember you're in the minority and your issue will most likely be fixed soon.

Check the maintenance records... you probably blew out the hot section of the engine while experimenting with the reverse thrust functionality. Been there, done that :-).

While trimming right rudder for takeoff definitely helps for a normal departure, it will aggravate the yaw over-sensitivity even more if the takeoff needs to be aborted. Cutting power on the roll will quickly result in S-turns across the runway (if not into the grass)... adding some reverse thrust into the mix will make it even more "exciting". I have not had the pleasure of trying out the MFG Crosswind pedals; but I feel pretty confident that they are orders of magnitude better than CH pedals when it comes to precise control inputs. Setting a (nearly) linear control response with the CH pedals is just a bad idea under any circumstance (full right slider for the win :-)). Speaking of trim... has anybody noticed any issues with elevator trim? Setting recommended takeoff trim results in a pretty pronounced nose up tendency after rotation. Flying a standard 3 degree ILS glideslope with full flaps requires over 90% nose-down trim to stabilize. Seems like it could also benefit from a little fine-tuning.