Throttles and flaps activated at startup

[macwino]

This is a follow-up to an earlier post by John Veldthuis concerning this problem, for which no resolution was ever reported by John. See viewtopic.phpf=54&t=67491&p=418952&hilit=plane+moving#p418952.

I have experienced a similar problem that has vexed me for several days now. I too am using a Saitek yoke and 2 throttle quadrants. I am running XP SP2, FSX SP1, and fsuipc 4.25. I have not loaded the Saitek drivers because I want fsuipc to see the Mode key on the yoke which I use for my button programming.

I was setting up the yoke and TQs for my various planes and all seemed to be going well. Then, all of the sudden, any plane that I loaded was loaded with the throttle at a level above idle that caused it to accelerate down the runway. The TQ's throttle lever was in the idle position and there was a wide idle range in my calibration so there could be no confusion here. An infinitesimal nudge of the throttle lever would reset the RPMs to idle and the plane would eventually roll to a stop on its own or under my braking pressure. This happened with both single and dual throttle planes.

I tried all of the fixes mentioned in John's thread: Redoing my default startup flight, redoing my calibrations, insuring there were no FSX conflicts, etc. I also performed a Registry tweak that was supposed to remedy any problems with the Saitek settings. Nothing worked. And remember, I had set up perhaps 5 or 6 planes in fsuipc before this problem suddenly arose. And the problem just didn't affect the plane that I was working on. It affected all planes that I'd previously configured with buttons, axes settings, config settings, etc. Now all of my planes would load with high RPMs such that they careened down the runway unless I was attentive enough to have my feet on the brakes and nudge the throttle a bit so as to reset it to idle.

I finally decided to rebuild my fsuipc ini file from scratch, one plane at a time, and testing after each plane was added. This seemed to eliminate the problem. I thought that my fsuipc ini file might have become corrupted and that incremental rebuilding was solving the problem. I was simply re-entering the same settings as I'd used before, although the calibration settings might naturally be slightly different but not in a material sense.

When I was done with about 6 or 7 planes, the problem re-appeared - but in a different context. Now it was that any plane I loaded was lowering its flaps to the first position. And, again, the TQ's flaps lever was in the full up position before loading the plane and a slight nudge on the flaps lever would cause the flaps to return to the Up position where they should have been on loading.

This time, however, I had saved a copy of my fsuipc.ini file after configuring each plane. So I tried using these saved ini files to see if something I had done in a subsequent ini had caused the problem. But it made no difference. Even if I went back to the very first ini file I created - with my global settings - any plane loaded immediately lowered its flaps to the first position.

The only way I could avoid this happening was to allow fsuipc to create a pristine ini and then start rebuilding the file again plane by plane. Obviously, this is not a viable long-term solution. While I can live with the flaps situation, if the throttle situation were to suddenly reappear - which is not unlikely - that would be a problem for I often am doing other things while a flight is loading and can easily miss the point where the plane has finished loading and the brakes need to be applied and the throttle lever nudged to prevent it from taking off down the runway.

Any thoughts on what is happening here and how it can be remedied?

Thanks, Robert

[mtjoeng]

I had a couple of these happening, and after lots of hair pulling, indeed the 1 thing that works is deleting the .ini and all problems are gone.

What I do now is tediously make backups of the .ini with any change of every setting.

Having said that, I have the guesstimation that the problem lies with bad USB 'writes', all of a sudden, the USB is off the 'calibrated' settings, and FSuipc goes berzerk.

I have a lot less poblems, now that I have reverted my OS back to XP (pro SP2) [even the /3GB switch gives problems], before I had FSX installed on Vista64x (the box has 4GB) and FSX was reeeeeaaallly faaaast, until I got Simconnect dropouts, Vatsim bad voice connects and 'over the network' button drops (ones in a while, just to go mad).

Therefore, I backup every time, and when something goes bad, Pull Out your USB's, Restart your PC, connect USB's and check the proper calibration of your devices in 'game controllers', and only then start FSX.

When things go bad still, perhaps you also 'upgraded' to Vista or Vista64, and as I said, my guesstimate is, that should only be done with a Recent model motherboard, that's specifically designed for Vista (and proven?!).

In my case, a Asus P5K, still isnt good enough, I noticed FSX demands just a looooooot more from hardware, than any other program/game (Nerver a problem with any strategy games), and all my clever shortcuts for speed, haunt me, when I start adding addon's (FSInn, FSCommander, ASX, and simconnect controlled aircraft panels)

my 2 cts

[Pete Dowson]

This time, however, I had saved a copy of my fsuipc.ini file after configuring each plane. So I tried using these saved ini files to see if something I had done in a subsequent ini had caused the problem. But it made no difference. Even if I went back to the very first ini file I created - with my global settings - any plane loaded immediately lowered its flaps to the first position.

This is because it really cannot be an INI file problem, but must, I think, be a device problem. The INI file parameters for your calibrations are really just very simple limit values, and they aren't going to suddenly change, or correct themselves simply because you nudge an axis. The fact that nudging the axis does fix the value really indicate that some spurious value has arrived for it beforehand.

FSUIPC will only ever act on a joystick input value when it sees a change occur, so FS initial values will be left as they are until you move the axis. This does mean, of course, that the values in FS may not initially accord with the placement of the levers, not until you move them -- this is why it is important to save flights with predictable axis settings (like idle for a parked aircraft).

I could, I suppose, make FSUIPC always send a "zero" to FS for all the axes it is responsible for, on first loading, but I feel this is not really a good idea as your startup flight might really need it someplace else. It shouldn't really do anything until asked to act on an input change.

Anyway, I've made a note to double-check all this, to see if there's any odd initial condition which can arise -- this can of course only happen once, on FS first loading, in any case -- certainly not on an aircraft loading subsequently -- unless, possibly, you are assigning different axes for different aircraft, so previously unseen axes can suddenly "join the party"?

Maybe FSUIPC should deliberately discard the first so many seconds worth of joystick values it sees, afterafter what, first loading? First seeing this axis?

Maybe some extra clarity as to exactly WHEN this problem occurs is needed first. The title of the thread suggests startup of FSis that right? Only at FS startup? If not, when, exactly?

Another thought. Possibly they are USB devices and you have Windows cutting power to them when there's no action on them for some time -- go to the device manager and make sure you have power management switched off for all USB hubs, every USB place where there is such an option.

Regards

Pete

[macwino]

Pete, here's the clarification you asked for, and I apologize for not being more explicit the first time.

The problem indeed only occurs upon the initial launch of a flight after a fresh launch of FSX. In other words, it occurs when you launch FSX, then load a saved flight (of course, with throttles at idle and flaps up) or a new flight created in the Free Flight window. And just to cover all bases, the axis levers are at the idle and flaps up positions.

The problem does not occur if you change the aircraft once the initial flight is loaded, or if you quit the initial flight and load another flight that's either saved or created in the Free Flight window. So long as you do not relaunch FSX itself, the problem does not seem to recur on any subsequent flights.

Again, the problem only happens with the first flight loaded after a fresh launch of FSX.

I checked Device Manager and turned off the Power Management for all my USB Hubs. It had been activated for all. The problem still remains after making this change, but perhaps this kind of change will take time to have any impact in preventing this in the future. In the meantime, I still need to get things back on track by rebuilding my fsuipc.ini, which so far appears to be the only fix available, albeit a temporary one at that.

I understand how the fsuipc.ini can theoretically have no bearing on this problem. But the fact remains that my experience has been that once the problem arises, using a pristine fsuipc.ini file and then building it up from scratch appears to be the only way to eliminate the problem - for several hours at least. Don't get me wrong. I'm not questioning your conclusion or judgment. I'm just reporting what my experience has been so far. I'll leave it to your expertise to try and explain my observations.

As always, thanks for your willingness to look into this. I greatly appreciate it.

Robert

[macwino]

Mtjoeng,

I tried your suggestion of shutting down, removing the USB cables, booting up, and then re-inserting the USB cables and checking the calibration, which was fine. Then I installed one of my backed up fsuipc.ini files that had worked properly at one time and launched FSX. I checked to insure that all the FSX axis and joystick controls were deactivated. Then I launched a flight.

Unfortunately, the flaps were still being lowered at startup.

I also went through the same process again, but this time I tried copying my button and calibration settings into a pristine ini, but got the same result.

So for me, anyway, there seems to be no point in making an ini backup every time any changes are made. The only solution seems to be a tedious rebuilding of the fsuipc.ini from scratch, one plane at a time. And so far I've been unable to accomplish this, as I eventually run into a problem before I'm even half done - first with the throttles, then with the flaps, and who knows what next. This is all very frustrating, to say the least.

Thanks for the input. And I'm glad to see that the backup ini files are working for you.

Robert

[Pete Dowson]

I still need to get things back on track by rebuilding my fsuipc.ini, which so far appears to be the only fix available, albeit a temporary one at that.

But if "rebuilding" the INI fixes things, albeit temporarily, surely something, something unknown,must be changing the INIwhat and how? Obviouisly 2rebuilding" a simple text file to be identical to what it was before cannot possible make any change whatsoever.

That being the case, we need to track down wehat is changing it. And to do that I need to see your "working pristine rebuilt INI" and your "old corrupted original INI" to see what has been changed.

Do you think you can show me such a pair?

Regards

Pete

[macwino]

Pete, what worked with the throttle didn't work with the flaps. In other words, when I had the throttle problem, a rebuilt pristine fsuipc.ini file resolved the problem. However, when I rebuilt the fsuipc.ini this morning by having fsuipc create a new ini file and then adding my axes and calibrating them, the flap problem still remained. So unfortunately I've got nothing to send you that would be meaningful in troubleshooting this problem.

I'll keep experimenting and keep you posted.

Thanks, Robert

[Pete Dowson]

Pete, what worked with the throttle didn't work with the flaps. In other words, when I had the throttle problem, a rebuilt pristine fsuipc.ini file resolved the problem.

That is something impossible to imagine if the files were identical. If they are not, what could possibly be changing them?

However, when I rebuilt the fsuipc.ini this morning by having fsuipc create a new ini file and then adding my axes and calibrating them, the flap problem still remained. So unfortunately I've got nothing to send you that would be meaningful in troubleshooting this problem.

Okay. That sounds more reasonable. I'll keep it open.

Regards

Pete

[macwino]

Well, I've come up with what might be a solution. It came about when I decided to see if the flaps problem could be eliminated by resetting everything by just using FSX for the axis assignments without any involvement by fsuipc, and then reintroducing fsuipc back into the picture. This worked! I'll have to see how long it lasts and if it can be repeated if the problem arises again. Here's what I did:

I eliminated my fsuipc settings from the picture entirely by removing its ini file. Then I launched FSX and assigned all my axes from within FSX. (I had previously been assigning them in fsuipc.) Then I loaded my test flight and the flaps didn't move on loading and were properly set in the Up position. So all was as it should be. I then went into fsuipc and calibrated the flaps axis as it definitely needed calibration. So did the Elevator Trim axis. And all was still working fine. I then exited FSX, relaunched FSX and loaded my test flight. The flaps didn't move on loading and were properly set in the Up position. So the setup survived a relaunch.

Then I exited FSX. I swapped the pristine fsuipc.ini that I'd just created for a previously created pristine one with just my fsuipc axis assignments. I launched FSX and went to Controls and deleted all of the FSX axis assignments. Then I launched my test flight and the flaps didn't move on loading and were properly set in the Up position. Then I closed FSX, relaunched it, and loaded my test flight. The flaps didn't move on loading and were properly set in the Up position. So this setup survived a relaunch using a pristine fsuipc ini with axis assignments.

Then I exited FSX. I swapped the pristine fsuipc.ini with the axis assignments for the one I'd been using when the flap problem first arose and that I thought was corrupted. Then I launched FSX and loaded my test flight. It loaded properly without any flap problem. I closed FSX and performed a relaunch and reload of the test flight and all still worked fine. So it's apparently fixed - at least for now.

I'll have to see how it goes from here.

Robert

[Pete Dowson]

So it's apparently fixed - at least for now.

Yes, goodbut of course it is impossible to derive anything from that which points to whatever it might be causing the problem.

I really hate that sort of thing!

Best Regards

Pete

[mtjoeng]

I think you just went in and out of MS programming quagmire

similar example, there are - guesstimate - remnants of FS9 code in FSX

ever had 'lets push F10 for panel view' and you get the Kneeboard?

how does that happen?

when you would ask MS if they know what would cause such problem, they would say they dont know (or 'you should reinstall:)

it's because they really dont know

[macwino]

Call it what you will - quagmire, nightmare, whatever. Two and a half days wasted. Ouch!

Robert

[Pete Dowson]

Call it what you will - quagmire, nightmare, whatever. Two and a half days wasted.

I've checked the code in FSUIPC4 for axis readings and consequent actions, and it most certainly does not do anything with any axis value until it actually READS one from the joystick driver. Then it applies it according to your calibrations and so on. After that it only takes not of CHANGES to the value.

I can only think that when first initialised the driver's interface sometimes supplies a spurious value. It must vary as I've never experienced this.

Anyway, to counter this possibility, in FSUIPC 4.254 (and 3.784) onwards I am discarding the first 10 readings from an axis when first read. This should take care of the first half-second, approximately, of scanning.

Regards

Pete

[macwino]

Terrific! I look forward to giving it a try when released. In the meantime, I've gone almost 24 hours now and neither the throttle or flaps problems have reappeared. But I still cringe every time I load a new flight after a fresh launch of FSX. It will be nice when I can get over that.

Thanks,

Robert