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

You are right about that! It looked like a movie set of London yesterday morning around here. It's amazing that we got smoke like that from wild-fires 100 miles away! I feel very bad for those folks in eastern North Carolina.

Sounds like its time for me to slip in the ole Memtest86 cd tonight and let her cook all night. Thanks Pete. What you're saying sounds very logical. I have been a bit suspicious of this rather cheap Corsair memory I put in this machine anyway. Maybe I should spring for some G.Skill PI that I see on sale at Newegg.

Thank you Pete for your very thorough reply. Interesting, I was certain I saved off the correct report. I must have made a mistake on that somehow. It usually takes 15-20 minutes of flight for this to happen. Sorry about that. I mean to say the tree "C:\Documents and Settings\mhf\Application Data\Microsoft\FSX" In fact, here is the process I followed to delete FSX: (Isaved off my FSX.CFG and FSUIPC4.INI first) 1. Uninstalled FSX via "Add and Remove Programs" 2. Deleted "C:\Program Files\Microsoft Games\Flight Simulator X" 3. Deleted "C:\Documents and Settings\mhf\Application Data\Microsoft\FSX" 4. Deleted "My Documents/Flight Simulator X Files" I DID NOT delete "C:\Documents and Settings\All Users\Application Data\Microsoft\FSX" (didn't think about that) NOR SimConnect (wasn't aware of it). I am going to do this all again making sure I get the "All Users" and SimConnect parts. It has gotten very hot around here (over 100 deg F during the day) and I have wondered if perhaps that is a factor although I am leaving the machine powered off when I'm not using it, use plenty of ventilation in that room, and monitor my temps pretty carefully. My CPU/GPU/Bridge temps don't show any higher than they did during the winter months when all was working well. I do (and have for quite a while now) have my CPU and memory overclocked a bit. It sounds like I should put the machine back to a perfectly stock state and try this all again and see if it is overclocking that is causing this. I have gone the extra mile with case fans and coolers for my CPU, North/South Bridge coolers, etc. and feel pretty confident that my temps are not high. The other game I play is Aces High which pushes the hardware pretty hard and I have never had a single freeze or CTD with it. I realize that's not necessarily "apples to apples." Thank you again for giving this the attention that you have.

I have recently begun to get crashes with FSX (for the last few weeks) during flight. It's the type of crash where you are prompted to send an error report off to MS. I'm pretty sure I've isolated it to FSUIPC. I have collected the error report as well as the FSUIPC.ini and log files here: http://snomhf.exofire.net/data/FSUPIC4errorrpt.zip Here is what I have done to isolate this problem: Completely removed FSX from my system including the FSX.cfg file and the entire tree under Documents And Settings. Also including was the only other module I use (SIMCharts) and the Acceleration pack. 1. Installed only FSX up through SP2 (rather than Acceleration) as well as FSUIPC4 with the ini that I had been using all along. I did not install the Acceleration pack or SIMCharts. As best as I can tell, I have a "stock" install at SP2 at this point except for FSUIPC. The crashes still occur. 2. Tried using a default FSUIPC4 with the setup from (1). Crashes still occur. I tried both FSUIPC 4.20 and 4.28. 3. Uninstalled FSUIPC4. Tried deleting my FSX.cfg file and allowing FSX to create a new one. Ran for a couple of hours with no crashes. I then put my "normal" FSX.cfg file in place but turned on controllers inside FSX since I had FSUIPC uninstalled. Ran a couple more hours with no crashes at all. 4. Installed FSUIPC4 with the basic FSX.cfg, turned off controllers in FSX and the crashes returned. 5. Tried settings "Normal Settings" in FSUIPC4 with no positive results. I have obviously changed something that is causing this as I have been running with no problems until a couple of weeks ago. I just can't figure out what has been changed. Right now, the only thing that seems to work is to run without FSUIPC. I can run both Acceleration Pack and SIMCharts without incident. Thanks for any advice/help in this matter. -mark

FYI I have discovered that by moving a couple of controls while the flight is loading cuts down the occurrence of the axes not getting scanned properly. It now only seems to do it maybe one out of ten times.

Pete, Good suggestion. Bob is my buddy. I talk with him all the time. I should have thought about asking him about this. thanks -mark

Ah, I do have my mini-stick on the Pro Throttle mapped to the mouse in CHCM. I'll try disabling that. I don't really need that anyway. Yes. No. I was careful to make sure there is no controller references at all in FSX. Yes. That works just fine. Thanks. I'm pretty certain that is not that case. I'm really careful with these things. I'm a pretty experienced user of CH and the CM but reasonably new to FSUIPC (the registered version anyway). I will double check that. Yes. I'll experiment with that and see if it makes a difference. Thank you very much for your good advice Peter. I am pretty experienced with CHCM and use a lot of pretty complex assignments that I'd hate to lose by going direct mode. I really doubt that CHCM is the issue anyway since I don't configure any axes there (except the PT mini-stick which I am going to delete). This is really a pretty minor annoyance. As I said, it's much like a check-list item. I'm just techy enough to want to try and fix it though. :) I am really amazed at how much better it is to let FSUIPC manage my controllers than FSX. Things are rock solid! That was not the case before. There always seemed to be a bit of a sluggishness to the controls and a bit of a delay somehow. It was especially noticeable when flying helicopters. Much, much better with FSUIPC.

I have been using a registered version of FSUIPC4 for about about five months now. This problem doesn't happen every time (maybe 50%). When I start a flight, my plane is uncontrollable. It does not respond properly to any of the controls. If I immediately go to the FSUIPC module and go to the "Axis Assignment" tab and do a "Rescan" on my ailerons, elevator, rudder, and sometimes trim axes and then return to the flight, everything will be fine. It's as if FSUIPC needs to be "notified" of my controllers else it will not set them up properly. BTW, I use FSUIPC exclusively to control all my axes and have all controllers disabled in FSX itself. My buttons are all controlled via CH Control Manager and the only thing FSUIPC controls is my axes. Though this is not a serious problem (I generally just treat having to go through this process as the "check for proper control surface movement" part of the pre-flight checklist. I am curious however why this happens and why I don't see postings of others having this problem. Any ideas? Thanks so much! -mark