snomhf

Now that the smoke is clearing a little bit on all this, :) I've been wanting to ask why the default for assigning axes is "Send to FS as normal axis" rather than direct. I've only been using the registered FSUIPC for a few months. Anytime you begin to use an unfamiliar program, you tend to use whatever defaults are already there and then fine-tune later. Is there a reason why "direct" is not the default? Course, I would have started this thread several months earlier if that were the case. :D No biggie. Just curious. Loving this direct mode! Thanks again -mark

4.294 works perfectly for me! Three hour cross-country and NO problems of any sort. Better than ever actually. The controllers behave themselves better than I've ever seen them. The responsiveness is fantastic! Thanks again Pete!

On the move

I've got so many things to move, I don't always remember to move them all! :lol: Thank you Pete for the great work you've put into this. We really appreciate the support you give us. I know I certainly do.

Sure. It's on the way

Well, I almost hate to say this as I hope I'm not coming back an hour later to retract. (Been there, done that) But... I've flown about two hours now with 4.291 and NO CTDs at all! I have double checked that I indeed am running direct, no lurking PollIntervals or anything like that. My assessment at this point is that this problem is solved. Looks like we can point our fingers at SimConnect. WTG Pete! I'll keep monitoring obviously and report if I have a crash. Certainly I've never gone this long without one before since I have gone direct. BTW, if you recall, I had started another thread about my controllers not getting sensed correctly and I had to go into FSUIPC after getting in the plane and wiggle them to get them working. Well, I have seen none of that with direct mode either so this appears to have solved both of those problems! Thank you Pete! -mark

No, it's us North Carolinanians that are uncovering all the bugs! :lol:

Perfectly logical explanation Pete. I was wondering if the extra logging was slowing things down just enough to make it work. I have seen that sort of thing before in other contexts. So, should I go full bore with 4.291 testing and just forget about earlier versions? Does this mean I should do no more with PollInterval or trying to get you good logs (unless 4.291 fails of course)? New thought: It seems to me that if you are right about your "extra logging theory" then if I turn off SimConnect logging in 4.287, I should start seeing CTDs again as it will effectively be just like 4.28 right? I may try that just to try and prove your theory.

Last night was a little frustrating. First, I went back to the .ini that uses direct axis modes, set up SimConnect logging and started the famous flight that always failed and got a CDT within two minutes! Great! Boxed it up and sent it to Pete. Pete replied back saying that he had put out a newer version of FSUIPC (4.287, I was using 4.28) and would I repeat the test again with 4.287. Well, when I installed the 4.287 dll, I could not get the darn thing to crash again after that! I had been playing with PollInterval (which did seem to prevent CDTs BTW. Need more testing on that) so my first thought was I had forgotten to remove the variable from the ini. However, it appears that going to 4.287 works for some strange reason. Just for the heck of it, I decided to try the new 4.291 and made two 20 minute flights (the famous one that faithfully crashes) and I was able to complete both of them without incident. I'm not sure what this all means. I can certainly understand why 4.291 would work but I surely do not understand why 2.87 would also work! I didn't get started on this stuff till late last night and sort of rushed a bit. I'll take a more systematic approach tonight. Stay tuned.

Good point, except I would have to change what you're saying here to "freezes in SP2 or Acceleration" because I ran in SP2 (rather than Accel) all last week and the freezing behavior was exactly the same. I wish I had thought to try it before I loaded any patches. It would have been nice to know if it would freeze with SP1 or no patch at all. Oh well, sorry, I'm not going there. I've payed my dues. :) I have gone back to Accel now but since I'm not running my axes in direct mode, I'm seeing no freezes at all. BTW, I'm supposed to be getting different memory tomorrow so hopefully I can close the door on that possibility completely. I'll let you know what the different memory does.

Pete, I would be happy to be a guinea pig for any testing you'd like me to do. As I've said, I can reproduce this problem like clock-work within fifteen minutes. I have, to the best of my ability, eliminated hardware issues, faulty installation, etc. from the equation. I still have the FSUIPC.ini that fails on hand so it's a very quick swap to do it. I have a montage of equipment so to say I have "CH equipment" is not getting the true sense of it. My joystick has a Logitech Wingman board in it that controls the X&Y axes and a CH FighterStick board that controls my rudder and aileron trims. I have a CH Pro Throttle with Leo Bodnar's BU0826 board in it that drives my elevator trim, prop RPM and mixture axes. The only unmodified controllers I have are my CH Pro Pedals and CH Throttle Quad. You can see a picture of my gear if you're interested here: http://snomhf.exofire.net. There are also articles about my gear and other mods I do there if you're interested in any of that. I'm glad you explained about "send direct." I sure can tell the difference with respect to having to move all my controls while the flight is loading else my plane will veer all over the place because the controls were not sensed correctly. I don't recall that problem ever occurring with "direct." I would love to go back to "direct" if it wouldn't crash. Anyway, it's nice to be back up and running. I'm still going to try this G.Skill Pi memory as a test just to see if it makes any difference. I guess it's possible that I still have a memory problem that only "send direct" can find. This has been an education and actually sort of fun. One thing is for sure, I have a nice clean install of FSX now and thoroughly cleaned up and tested computer. :) -mark

I figured it out!! :D I'm actually feeling kinda stupid over this. About three weeks ago (interestingly enough about the time this problem began [exactly if I were to be honest] ) I read a help document on this forum describing how to set up CH gear with FSUIPC. I decided to read it just to see if there was any little tid-bit I was missing since my stuff (except for the annoying axis "non-wakeup" issue) was working pretty good. The guy was describing assigning your axes and he has you select: O Send direct to FSUIPC Calibration Well, I had it set this way: O Send to FS as normal axis for ALL my axes. I proceeded to delete all my axis assignments and set them to "Send direct to FSUIPC Calibration" so as to match what he was suggesting. I was mainly curious to see if it would help my controllers to "wakeup" better when I started a flight. Low and behold, it seemed to help quite a bit. Maybe it was just imagination but it really seemed better. The unfortunate part in all this was I didn't fly very much for the week that followed and I sort of forgot that I had made this change. It was after that that I began to see all these crashes I've described in this thread. Now, you would think that a guy who has been methodically eliminating ALL possibilities (re-installing FSX), deleting other add-ons, even un-overclocking, sweat testing and swapping around memory, CHDSK, De-frag, etc., etc. would think to try "Send to FS as normal axis" on my axis assignments (like I originally had done) but somehow I never thought to do that.... Until last night (after days of ripping my computer apart). Well, that fixed it! I have made three flights (total of about four hours) last night and today and not a single crash! There is NO way I could have gone fifteen minutes with "Send direct to FSUIPC Calibration" select for my axes. I never have been very clear on what these selections are but I sure won't forget which one to use from now on. Thanks for all who helped me; especially for the kind advice of Pete. Sorry to have bother you so much about this. I really should have been able to figure it out without making a public spectacle. Regards, -mark

I understand. I just figured I'd do it while waiting to borrow memory.

My memory just passed ten hours of stress test with Memtest86.

Well, I believe I've eliminated memory and overclocking as the problem. I'm going to borrow some G.Skill PI from a friend of mine next week and check it just to be sure. Anyway, here is what I've done: 1. I ran Memtest86 for almost three hours and no errors at all turned up. You would certainly think that ought to do it. I have run it all night (8-9 hours) before but I would think three hours ought to do it since this crash is so reproducible. I'm going to start up Memtest before I go to bed tonight and let it cook all night. 2. I set all my clock speeds and overvoltage back to stock settings. FSX still crashes. 3. I have four sticks of Corsair XMS DDR2-800. I have tried pulling half of it and get failures with each set. That means if there are errors in the memory, they have to be in at least two sticks. I would think that unlikely. I did not try the six combinations of possibilities. :) One thing is for sure, if I delete FSUIPC (I simply rename the "modules" directory and create an empty one), I have YET to get a crash under any of these circumstances. As soon as I put FSUIPC back in, it crashes almost every time. I'm running out of things to try. :( If my logic is faulty, I certainly would appreciate being set straight. Thank you! -mark