Jump to content
The simFlight Network Forums

tacomasailor

Members
  • Posts

    21
  • Joined

  • Last visited

Everything posted by tacomasailor

  1. The change of axis assignment occurs before I ever enter Addons/FSUIPC - What "confirm the change" are you thinking about?Perhaps I am not explaining myself clearly 1 - I walk around the aircraft and verify that all flight controls, as viewed from the exterior of the aircraft, are working properly 2 - I takeoff and fly the aircraft for many minutes and all flight controls work properly 3 - I DO NOT enter ADDONS/FSUIPC 4 - SUDDENLY, while flying, the ailerons fail to move on the flight surface 5 - I verify the yoke or stick in the cockpit does move in the aileron axis 6 - I enter ADDONS/FSUIPC and do a Axis Assignment/Rescan for the X axis and see that the axis is assigned to Aileron Set 7 - I open FSUIPC4.ini and verify that axis X is set to AXIS_AILERONS_SET - 65763 Where, during the process above, could I have changed the axis assignment prior to the failure of the aileron surface response to yoke/stick movement? I don't mean to be contentious; but I am confused as to why you think this is operator error.
  2. In your post #2 you explained the difference between Axis Ailerons Set and Ailerons Set and that made sense to me. Today; I had been flying for five minutes - ( took off from KHNL and was headed SE with some strong trade winds blowing and the ailerons had worked well during the walk around and during the X-wind takeoff) and very suddenly the aileron flight surfaces stopped moving. The yoke in the VC was moving but the actual ailerons did not move. In FSUIPC I found the axis assignment was again set to Ailerons Set NOT Axis Ailerons Set - I switched the axis back to Axis Ailerons Set and again everything was working perfectly and I had an un-eventful flight. Do you have any idea what is causing the Axis Assignment to change during flight? I had made no changes in FSUIPC during the last several hours of flight. How do I prevent the axis assignment from changing?
  3. Sorry about the confusion the statement should have said "Ailerons on wing DO NOT MOVE and aircraft while in flight does not respond to VC stick movement in aileron axis. I don't know why the Axis Assignment was "Aileron Set" - I thought I always used " Axis Aileron Set" as you suggest. I've changed to "Axis Aileron Set" and have flown for a while with no problems. I'm hoping that the problems were caused by my inadvertent use of "Aileron Set" - If I have problems in the future - the first thing I will check, for any axis, is the "XXX Set" - vs "Axis XXX Set" Your response of: has apparently clarified my confusion on this matter. I mistakenly thought Joystick Calibration only worked if the axis was assigned in FSUIPC. The FSUIPC user Guide says "You have to set an axis in one of the Joystick pages first." in the first part of the joystick calibration section which I took to mean the FSUIPC Axis Assignment was necessary to gain Joystick Calibration. I know the earlier statement " So I added facilities for final ―tuning of joystick controls, once they‘ve been through FS‘s assignments and main calibration. " can be interpreted to mean the axis can be assigned in FSX and FSUIPC calibration will also be effective - but the latter statement confused me. Thanks for the quick response and I'm really hoping the Axis XXX Set clarification will solve all my problems.
  4. Vista32 Home Premium FSX/Acceleration FSUIPC 4.60a registered Saitek ST290Pro Joystick CH Pro Pedals No axes is assigned in FSX for either game controller but the controllers are enabled in FSX. Sensitivity is max and Null is minimum in FSX. Joystick was working perfectly in FSX while engaged in default flight. Reloaded default flight, which is Stock MS Piper Cub cold and dark on runway. I test the flight controls. Movement of joystick moves VC stick & cables for ailerons and rudder and VC throttle lever as appropriate. Ailerons on wing DO MOVE and aircraft while in flight does not respond to VC stick movement in aileron axis. The elevator works normally. Throttle (controlled by ST290) works normally Rudder works normally. Problem occurs in Stock MS aircraft, in payware, shareware, freeware aircraft - I've seen this problem in dozens of aircraft. Movement of joystick in X axis (as above) results in the following: FSUIPC Axis Assignment (AA) Rescan shows Joy #2 Axis X assigned to Aileron Set “Send to FS as normal axis.” AA In/Out values show linear response to joystick movement in AA - 16384 to +16383 with 0 as the center in AA. X axis delta set at 254. FSUIPC Joystick Calibration (JC) show NO In or Out for Ailerons. FSUIPC Console log shows no data for movement of stick in X axis. FSUIPC.ini shows the following before starting FSX AND after stopping FSX: [JoyNames] AutoAssignLetters=No 0=CH Flight Sim Yoke USB 0.GUID={57841C80-AC5F-11DE-8004-444553540000} 1=CH Pro Pedals USB 1.GUID={57841C80-AC5F-11DE-8003-444553540000} 2=Saitek ST290 Pro 2.GUID={7C034370-B339-11DE-8001-444553540000} [buttons] ButtonRepeat=20,10 [AutoSave] AutoSaveEnabled=No [GPSout] GPSoutEnabled=No [GPSout2] GPSoutEnabled=No [WideServer] WideFSenabled=Yes [Axes] 0=0X,256,F,65695,0,0,0 1=0Y,256,F,65762,0,0,0 2=0Z,256,F,66420,66423,66426,0 3=0R,256,F,66421,66424,66427,0 4=0V,256,F,66422,66425,66428,0 5=1X,2048,F,66387,0,0,0 6=1Y,2048,F,66388,0,0,0 7=1Z,780,F,65764,0,0,0 8=2X,256,F,65695,0,0,0 9=2Y,256,F,65762,0,0,0 10=2Z,256,F,65765,0,0,0 [JoystickCalibration] AllowSuppressForPFCquad=Yes ExcludeThrottleSet=Yes ExcludeMixtureSet=Yes ExcludePropPitchSet=Yes SepRevsJetsOnly=No ApplyHeloTrim=No UseAxisControlsForNRZ=No FlapsSetControl=0 FlapDetents=No ReverserControl=66292 Reverser1Control=66422 Reverser2Control=66425 Reverser3Control=66428 Reverser4Control=66431 MaxThrottleForReverser=256 AileronTrimControl=66731 RudderTrimControl=66732 CowlFlaps1Control=66162 CowlFlaps2Control=66163 CowlFlaps3Control=66164 CowlFlaps4Control=66165 SteeringTillerControl=0 MaxSteerSpeed=60 Throttle1=-16384,-512,512,16383 Throttle2=-16384,-512,512,16383 Throttle3=-16384,-512,512,16383 PropPitch1=-16384,0,512,16383 PropPitch2=-16384,0,512,16383 PropPitch3=-16384,0,512,16383 LeftBrake=15744,16380/24 RightBrake=-16123,16256/24 Aileron=-16380,-512,512,16380/8 Elevator=-16384,0,512,16159/8 Throttle=-16384,16383 Rudder=-15993,0,0,15488/8 I shutdown FSX (End Flight / Blue x in top right corner of Free Flight) and restart FSX and everything works as it should – all flight controls act normally!! This has happened many times over the last six months. It happens with ONE of the three flight control surfaces (rudder, aileron, elevator) at a time. Sometimes the problem occurs while flying – e.g. suddenly the ailerons (or rudder or elevator) on wings don’t move even when stick in VC moves. Summary: - VC cockpit controls (Any aircraft) shows appropriate movement - One of the three (aileron, rudder, elevator) do not move - FSUIPC Axis assignment shows good In/Out Data for ALL axes - FSUIPC calibration shows no data for one control surface - FSUIPC Console log shows no data for one control surface - Restarting FSX always resolves the problem - No apparent change (I used Context to compare Before/After) to FSUIPC.ini What do I do to keep my flight controls working normally through an entire flight?
  5. Tried that - didn't make any difference I tried many of the solutions recommended over the years by various folks - all they did was generate new varieties of the same problems. I don't see a downside to the delete / reinstall - the whole process only took a couple minutes. I just wished I'd kept the old .ini file to retry it after the new install
  6. I have been struggling with several weeks of very strange FSUIPC behaviors (4.60a and 4.645) CH Yoke, CH Pedals, Saitek ST290 joystick, FSX Acceleration and Vista 32. FSUIPC had been running pretty reliably since 2007. When I don't allow FSUIPC to load I have no problems with any of the flight controls. I verified that no axis was assigned in FSX controls, I disabled the game controller in FSX controls Several weeks ago the following (just SOME of the problems) - axis quits responding in FSX but Axis Assignment & FSUIPC calibration show good values - axis assignment shows good axis - rescan in a couple minutes shows a permanent change to different axis - Axis assignment shows good values but FSUIPC joystick calibration shows no input - An axis assignment suddenly changes in mid-flight e.g moving the mixture control on the CH Yoke is moving the mixture in the VC and suddenly starts moving the Throttle in the VC - rescan in Axis Assignment DOES NOT show the changed assignment - axis assignment shows good values and a good assignment but FSUIPC console shows no input - CS 727 flight controls only quiver when CH yoke is moved but axis assignment shows good values - everything is OK in FSUIPC - shut down FSX - restart FSX and most axes in FSUIPC are unassigned despite them being assigned in FSUIPC.ini I worked on the problem for dozens of hours and could find no common thread I verified there was only one copy of the FSUIPC dll in Modules NOTHING WOULD CONSISTENTLY FIX THE PROBLEMS I deleted ALL reference to FSUIPC - Modules, .ini, all entries in FSX.cfg I then reinstalled FSUPC (4.60) registered it, created all my axis and button assignments from a FRESH START ...NO MORE PROBLEMS!!! It's only been 12 hours and 4 hours of flight time but I've flown a lot of different aircraft and have stopped/restarted FSX/FSUIPC many times with no problems. Just a suggestion for those of you asking about "strange" behaviors - It is a quick and easy solution - I HOPE
  7. Peter, I am sorry I didn't get around to changing the polling as quickly as you wanted - it was 3 AM here when I was working on my last reply - I gave up and went to bed for a while. That also may explain why a couple of my comments were not so clear or easy for you to understand. I will test that option ASAP I am sorry I was not clear about this. 1) I wanted to use FSUIPC Joystick Calibration - there is NO IN/OUT raw data in Calibration until I assign an axis in FSX - but there is raw data in FSUIPC Axis assignment with NO Axis assigned in FSX 2) I assign an axis in FSX 3) I use FSUIPC Joystick Calibration 4) I unassign the axis in FSX but it is still assigned in FSUIPC 5) The Yoke lever moves the FSX control, FSUIPC Console shows the correct input, FSUIPC Axis Assignment Rescan shows the correct input, FSUIPC Joystick Calibration shows no IN/OUT data I have had the CH Yoke since it was new three years ago. It has always worked perfectly. Calibration of the Yoke using the CH Calibration tool (CH Control Manager v4.51] shows ALL axes to have very smooth and linear outputs. There is no spiking, no extraneous output, the appropriate numeric values through the full range of motion for each axis. FSUIPC Joystick Calibration also shows smooth linear data for the CH Yoke. As far as I can know I made no changes to FSX internals or CH drivers (I don't think there are any) prior to these problems beginning earlier this week. The last VISTA update was Dec 19. I did not notice these problems until around Dec 26/27. Yes - your are correct! I will concentrate on one axis and try to define the limits of the problem. HOWEVER If the error is hardware it is not in the CH Yoke - I have the identical problem with CH Pedals, and the Saitek ST290 Joystick. I will test the CH Yoke more and try plugging it into other USB ports (the game PC has eight) I will refine the details to the relevant minimum and send the Console Log and FSUIPC.ini to you when I get the details minimized and isolated. This morning I told FSX not to load FSUIPC (using manual load in dll.xml) 1) I assigned all axes for the CH Yoke 2) All axes work as intended and remain correct through an extended flight 3) Shut down FSX and then restarted FSX - all Yoke controls still work perfectly haven't gotten around to testing this morning in FSUIPC There is no huge rush on this problem. Happy New Year and thanks for the great product and support
  8. Peter - thank you for the quick reply. I am quite certain these problems are not caused by FSUIPC- I have been using FSUIPC for years and have never had a problem with it. CH Control manager run in Direct Mode (the only way I use it) allows for advanced calibration and response curves similar to your Joystick Calibration. I use Process Explorer t ensure no software other than FSX is running. The CH Yoke and Pro Pedals do not even have a driver as far as I can tell. I am very careful to ensure there is no duplicate assignments between FSX and FSUIPC controls - however see the following details. I fly many different aircraft and want to have controls that are specific to an aircraft or aircraft type and FSUIPC makes that much easier to accomplish than does FSX control assignments. Here are some more confusing details Started FSX assigned all axes and tested with Rescan. Shut down FSX Started FSX with FSUIPC Console Log sent to screen Z R V axes worked as defined (Throttle, Prop, Mixture) in both FSX where they moved the cockpit levers and in Axis Assignment. The FSUIPC console log shows the appropriate data After several cycles through full range motion of each axis I ended up with: Axis Z – Throttle Set – moving Yoke Throttle moves the cockpit Throttle. Console log shows Axis: Cntrl = 65697…etc Axis Assignment window in FSUIPC shows the appropriate raw data and Rescan shows Throttle Set is to be sent to FS Axis R – Prop Pitch – moving Yoke Prop lever does not move the cockpit lever Console log shows no input data for Axis R Axis Assignment window in FSUIPC shows the appropriate raw data and Rescan shows Prop Pitch Set is to be sent to FS Axis V – Mixture – moving Yoke Mixture lever does not move the cockpit lever Console log shows no input data for Axis V Axis Assignment window in FSUIPC shows the appropriate raw data and Rescan shows Mixture Set is to be sent to FS FSUIPC Joystick Calibration FSUIPC Joystick Calibration shows NO real time data for ANY Axis – even for the Axes that work – X (Ailerons) Y(Elevator) Z(Throttle) – Those axes do move the flight controls in FSX ALL axes (X Y Z R V) show the appropriate real time data in Axis Assignment when I move the YOKE control. But in Joystick Calibration NO axis shows any IN or OUT data. ALL axes are shown as set but no real time data is shown for IN / OUT when I move any axis. IF I assign the axis in FSX OPTIONS/SETTINGS/CONTROLS then FSUIPC Calibration shows the correct IN/OUT data. I do the FSUIPC Calibration and then go back to FSX and unassign all axes in the Controls axes assignment. After I do that the controls still work in FSX but I can no longer Calibrate them in FSUIPC. Then I move the mixture lever on the Yoke and the whole problem sequence starts again. I thought the whole point of FSUIPC axis and button assignment was to eliminate the need to assign and mange axes and buttons in FSX due to the limited flexibility of FSX controls. Do I have a fundamental mis-understanding here??
  9. I am suffering several problems in FSX with CH Yoke usage and control – some intermittent, some new, all very puzzling. None of these problems are specific to any aircraft. Overview: Moving a Yoke lever for Throttle, Prop, Mixture sometimes results in FSUIPC reassignment of one or all axes to other controls. This happens in FSX flight and in FSUIPC Axes assignment. Sometimes moving a lever results in a lost assignment in one or more axes. When moving a Yoke lever FSUIPC console sometimes shows no data even though the Axes Assignment window shows good data. FSUIPC4.ini shows good values but the first movement of a lever in FSX or in FSUIPC moves the wrong lever or no lever. Console log data shows one line of good data and then one or more lines of incorrect data for the single lever movement. Many more details follow! FSX/Acceleration VISTA 32 Home Premium– all current maintenance CH FlightSim Yoke USB – three years old NO OTHER game controller plugged in. I calibrate Yoke with CH Control Manager v4.51 – all axes and buttons work correctly and send the appropriate data to Control Manger. I verify that no axis is assigned to any control in FSX. FSUIPC 4.645 registered (same problems in 4.60a) I am a long time experienced user of FSX and FSUIPC and thought I understood these things pretty well. This problem has me scratching my head. DETAILS. 1) Axes assignments for Z R V move between the three axes while flying or during ground testing. For example – Throttle/Z, Prop/R, Mixture/V work OK and then suddenly, during one movement of one Yoke lever the assignments change to Throttle/R, Prop/Z, Mixture/V OR Throttle might be assigned to both Z and R. When this happens one of the Yoke levers will not move the lever in either the VC or 2D cockpit. The reassignments can be in any combination. The change in assignment is often NOT for the lever that moved, e.g move the Yoke mixture lever and the prop control is reassigned to axis V. Subsequent Rescans and Yoke lever movements may or may not result in the correct control being assigned. If it is – the VC or 2D lever may or may not actually move. 2) Same as 1) above except the assignment for one or more axes is lost when a lever is move. Sometimes the lost assignment IS NOT the lever that is moved. A 2nd Rescan in FSUIPC Axes assignment sometimes reassigns the correct control set, sometimes a randomly different control set, and sometimes never assigns a control set. Subsequent Rescans and Yoke lever movements may or may not result in reassignments. 3) While testing and writing the FSUIPC data to the console log I see the following. Move Yoke Mixture lever Axis: Cntrl = 65773 …Param,=-15733 Mixture Set Axis: Cntrl = 65821… Param =0 Throttle2_Set Axis: Cntrl = 65820… Param =0 Throttle1_ Set Any additional movement of the Yoke Mixture results in NO additional output to the console. However – while moving the Yoke Mixture lever -> The AXES ASSIGNMENT Window in FSUIPC shows the correct axis for Mixture Set and shows the correct raw data for axis V. Doing a Rescan for the Yoke prop lever shows no assignment but does show the correct data for the R axis. And the Yoke throttle lever works as it should. If I then go back to move the Yoke mixture lever it may or may not work correctly. Sometimes the Rescan shows the correct Mixture Set and correct raw data values for the V axis but the VC/2D lever does not move (console shows no data when moving the Yoke lever). Sometimes the VC/2D lever does move ((console shows the correct data when moving the Yoke lever) The sequence shown in 3 above is quite common. 4) I clear all axes assignments and use three more Rescans to verify there are no axis assignments. I then rescan one Yoke lever and assign a control to it – I then rescan the other Yoke levers and often find the same assignment to one of them. 5) I get all three axes set “normally” in FSUIPC axis assignment and return to FSX but DO NOT touch any controls or levers. I then return to FSUIPC Axes assignment and rescan ONE lever and find it is already reassigned to a different axis. At that point the ONLY time I have touched a lever was to Rescan it. The console log shows NO DATA for any axes movement between the Rescan that did the assignment and the Rescan that found the incorrect assignment. The console log shows no data for the 2nd Rescan even though the Axes Assignment window shows the correct raw data and an incorrect control assignment. When I close FSX and look at FSUIPC4.ini I always see the correct modification timestamp for the FSX closure and I see the [Axes] assignments for all axes are correct, e.g. 0R,256,F,65767,0,0 – even when I close FSX with inoperative Yoke levers and missing or duplicate assignments in the Axes Assignment window. I have tried assigning the axes to FSUIPC Calibration and I have tried sending them to FS normal axis. I get all the same problems in both cases. None of these problems occur with the Wheel (X/Y axis) – they work correctly and never get reassigned. I have also never seen the button assignments change. Here is a log of a brief flight - this is ALL the data except for redundant throttle data ********* FSUIPC4, Version 4.645 by Pete Dowson ********* Reading options from "F:\Program Files\Microsoft Games\Microsoft Flight Simulator X\Modules\FSUIPC4.ini" Trying to connect to SimConnect Acc/SP2 Oct07 ... User Name="blanked out” User Addr="blanked out" FSUIPC4 Key is provided WIDEFS7 not user registered, or expired Running inside FSX on Windows Vista (using SimConnect Acc/SP2 Oct07) Module base=61000000 Wind smoothing fix is fully installed DebugStatus=15 94 System time = 30/12/2010 19:46:58 94 FLT path = "C:\Users\Administrator\Documents\Flight Simulator X Files\" 94 FS path = "F:\Program Files\Microsoft Games\Microsoft Flight Simulator X\" 500 LogOptions=10000000 00000001 500 SimConnect_Open succeeded: waiting to check version okay 1857 Running in "Microsoft Flight Simulator X", Version: 10.0.61637.0 (SimConnect: 10.0.61259.0) 1857 Initialising SimConnect data requests now 1857 FSUIPC Menu entry added 1904 C:\Users\Administrator\Documents\Flight Simulator X Files\Baron at KTIW NO scenery.FLT 1904 F:\Program Files\Microsoft Games\Microsoft Flight Simulator X\SimObjects\Airplanes\beech_baron_58\Beech_Baron_58.AIR 29313 System time = 30/12/2010 19:47:27, Simulator time = 12:34:34 (19:34Z) 29313 Aircraft="Beech Baron 58 Paint1" 29453 Advanced Weather Interface Enabled 79031 *** AXIS: Cntrl= 65697 (0x000100a1), Param= 14080 (0x00003700) THROTTLE_SET < MOVED THE YOKE THROTTLE – WORKS OK 79031 *** AXIS: Cntrl= 65697 (0x000100a1), Param= 10624 (0x00002980) THROTTLE_SET 79077 *** AXIS: Cntrl= 65697 (0x000100a1), Param= 7808 (0x00001e80) THROTTLE_SET … DELTED A BUNCH OF THROTTLE DATA 84584 *** AXIS: Cntrl= 65767 (0x000100e7), Param= 15104 (0x00003b00) PROP_PITCH_SET<=MOVED THE YOKE PROP PITCH – OK FOR A WHILE 84584 *** AXIS: Cntrl= 65767 (0x000100e7), Param= 12800 (0x00003200) PROP_PITCH_SET 87642 *** AXIS: Cntrl= 65697 (0x000100a1), Param= 12800 (0x00003200) THROTTLE_SET <=STILL MOVING THE PROP PITCH LEVER 87642 *** AXIS: Cntrl= 65697 (0x000100a1), Param= 7680 (0x00001e00) THROTTLE_SET 87657 *** AXIS: Cntrl= 65697 (0x000100a1), Param= 1152 (0x00000480) THROTTLE_SET 87689 *** AXIS: Cntrl= 65697 (0x000100a1), Param= -6761 (0xffffe597) THROTTLE_SET 87689 *** AXIS: Cntrl= 65697 (0x000100a1), Param= -11182 (0xffffd452) THROTTLE_SET 87720 *** AXIS: Cntrl= 65697 (0x000100a1), Param= -16384 (0xffffc000) THROTTLE_SET 95301 *** AXIS: Cntrl= 65773 (0x000100ed), Param= 15360 (0x00003c00) MIXTURE_SET <=MOVED THE YOKE MIXTURE LEVER – OK FOR A WHILE 95301 *** AXIS: Cntrl= 65773 (0x000100ed), Param= 13824 (0x00003600) MIXTURE_SET 95317 *** AXIS: Cntrl= 65821 (0x0001011d), Param= 0 (0x00000000) THROTTLE2_SET < STILL MOVING THE MIXTURE LEVER 95317 *** AXIS: Cntrl= 65820 (0x0001011c), Param= 0 (0x00000000) THROTTLE1_SET *** AT THIS POINT MOVEMENT OF THE PROP PITCH AND MIXTURE LEVERS RESULT IN NO ADDITIONAL LOG DATA NOR DO THE COCKPIT LEVERS MOVE – FSUIPC AXIS ASSIGNMENT SHOWS VALID RAW DATA AND THE CORRECT ASSIGNMENTS AT EACH RESCAN *** 143646 Sim stopped: average frame rate for last 82 secs = 91.8 fps 143646 Average weather filter write interval in that time = 4110.6 msecs [Log closed by user request, and continued in new file] 158295 System time = 30/12/2010 19:49:36, Simulator time = 12:36:21 (19:36Z) 158295 *** FSUIPC log file being closed Average frame rate for running time of 89 secs = 88.0 fps Average weather filter write interval in that time = 4473.3 msecs Memory managed: 55 Allocs, 54 Freed ********* FSUIPC Log file closed *********** ************** MORE DETAILS *************************** Started FSX & assigned all axes and tested with Rescan. Shut down FSX Started FSX with FSUIPC Console Log sent to screen Z R V axes worked as defined (Throttle, Prop, Mixture) in both FSX where they moved the cockpit levers and in Axis Assignment. The FSUIPC console log shows the appropriate data After several cycles through full range motion of each axis I ended up with: Axis Z – Throttle Set – moving Yoke Throttle moves the cockpit Throttle. Console log shows Axis: Cntrl = 65697…etc Axis Assignment window in FSUIPC shows the appropriate raw data and Rescan shows Throttle Set is to be sent to FS Axis R – Prop Pitch – moving Yoke Prop lever does not move the cockpit lever Console log shows no input data for Axis R Axis Assignment window in FSUIPC shows the appropriate raw data and Rescan shows Prop Pitch Set is to be sent to FS Axis V – Mixture – moving Yoke Mixture lever does not move the cockpit lever Console log shows no input data for Axis V Axis Assignment window in FSUIPC shows the appropriate raw data and Rescan shows Mixture Set is to be sent to FS
  10. Peter, :D I think the problem is solved - I deleted the fsx.CFG file and allowed FSX to rebuild it. Now all problems are gone and I can fly any of the previously 100% fatal FSUIPC autosaved flights. :D DETAILS FOLLOW: Was I chasing the wrong problem? The first thing I do EVERYTIME I start FSX is go into SETTINGS/Controls and check the Control axes for the CH Yoke USB. In the Assignment List I see the following (I call this the ORIGINAL Control Settings): Aileron axis X axis Elevator axis Y axis Engine 1 mixture axis – Y Rotation Engine 1 propeller axis – Z Rotation Mixture axis Axis 04 Throttle axis Z Axis Propeller axis unassigned All other engine controls unassigned If I leave those settings as shown – FSX generates the fatal error as soon as I touch a control in a cold dark cockpit or even when I try change the control settings while sitting in a cold dark cockpit. I can change the settings shown above to the following: Aileron axis X axis Elevator axis Y axis Engine 1 mixture axis unassigned Engine 1 propeller axis unassigned Mixture axis Y Rotation Throttle axis Z Axis Propeller axis Z rotation All other engine controls unassigned I save those settings into a named configuration file NEW Control Settings. I then fly as much as I want – wherever I want with no errors. Just to be sure the NEW settings are saved I load another config file, fly a bit, and then reload the NEW file and see the corrections I show above. However, FSX does generate a fatal error when I gracefully close the program. When I restart FSX I find the ORIGINAL CH Yoke USB control axis control settings with the incorrect Axis04 setting. Those settings will always lead to a fatal error. When I Load the saved (NEW Control Settings) I find the same settings as were in the ORIGINAL Control Settings. If I change them (before starting a new flight) I can again fly with no problems. … The cycle repeats endlessly with no changes to the CH Yoke USB control axes being “remembered” from one execution of FSX to the next. I then deleted fsx.CFG and allowed FSX to start with it’s chosen defaults. I still see the same CH Yoke USB control axis settings shown above in ORIGINAL. I change those settings to be as shown above in NEW. I saved those settings as NEW Control Settings. I can now fly any plane at any airport with any slider settings I wish. When I end the flight and close FSX I receive no fatal error. When I restart FSX I find the same CH Yoke USB control axis settings as I had saved in NEW (i.e. correct axes settings). FSX is now saving and reusing the correct configuration file. It appears that something was corrupted in the fsx.CFG file that forced the same CH Yoke USB control axis settings to return to the same corrupt or incorrect values no matter how I had set them and saved them prior to ending FSX. Deleing the fsx.CFG file and allowing FSX to load it’s default values now allows me to save the same CH Yoke USB control axis settings I want to use for my customized installation. I can now reload and fly any of the old FSUIPC autosaved flights that had been 100% fatal prior to the deletion of fsx.CFG. When I now reload the fsx.CFG that had been causing the fatal errors, and preventing the save of the corrected CH Yoke USB axis settings, everything still works perfectly, including saving changes to axis settings. I don’t know what the cause of this mess was but thanks for the suggestions about deleting fsx.CFG. As an aside – if you are really into debugging – I can send you a Windbg CALL STACK, register list, and disassembled code listings for the fatal error. That seems to be a waste of time since deleting and rebuilding the fsx.CFG file solved all the problems.
  11. Thanks for the quick reply - I have isolated part of the problem but still experience a fatal error every time I close FSX. I moved all saved flights out of the FSX directory to a location where I can selectively reload them into the directory for testing. There were no saved flights available to FSX in the following scenario, except when I reloaded some of the 100% fatal flights to test my approximate fix. The fatal error will occur (under the conditions described below) when the flight begins (new execution of FSX - new flight – not a saved flight) – sitting on the runway with engines at idle. Raising and lowering flaps, turning lights on/off, looking at the GPS usually causes no problem but occasionally will cause the fatal error. Trying to change a radio frequency or pressing the G button always causes a fatal error as does selecting OPTIONS/Controls – the program freezes when I click on controls. This occurs sitting still on any runway at KSAN (but not at San Diego/North Island or San Diego/Brown Field), at KLAX, KJFK. It occurs with the stock Baron, King Air 350, Carenado Seneca, Carenado RG182 with any variety of slider settings. The problem occurs with and without FSUIPC running. The fatal error sitting on the runway only occurs during the day – if it is dark I can take off/fly around/land with no problem, other than poor piloting technique. The problem does not occur at KTIW, KTCM, KBFI, or KSEA under any conditions I can find. I checked the control axes settings (in FSX not in FSUIPC) for a CH Yoke and found them set appropriately – except MIXTURE was set to Axis04. I had not noticed that previously since I use automixture most of the time. I then deleted all settings and saved the null settings. I then manually reassigned all the settings back to the settings as they had been with the fatal errors (with mixture set to Y Rotation). I can now load and fly any of the FSUIPC Autosaved flights that had been 100% fatal and fly them with no problem. I can also operate out of KSAN, KLAX, KJFK with no errors. Just changing the Mixture to Y-Rotation and not saving the configuration does not solve the problem. EXCEPT – if during normal FSX operations I click on OPTIONS/Control – the screen freezes and I eventually get the “fatal error” message. I can change Control Settings with no problems as long as I have not started a flight or mission. Even when I see no fatal errors in FSX operations - I still get the fatal error every time I close FSX. When I reload the control settings, via a saved settings file, that had been in effect with the fatal error flights I again get the same pattern of fatal errors in FSX. SO – I am down to two fatal error situations 1) Every time I close FSX – I guess this doesn’t matter 2) If I try to change the Control settings in flight or even with a cold dark cockpit.
  12. Thanks for taking the time to read and consider the following: I am a long time user of FSUIPC & FSX/Acceleration and have never had a problem with FSX or FSUIPC until Oct 16, 2009. Beginning on the 16th; almost every flight in FSX would end with a frozen screen but ongoing sound. Eventually a ‘fatal error” message would appear and FSX would end when I selected that option. Appcrash data shows the error is always a c0000005 at the same address,(everytime), in CONTROLS.DLL. The error occurs with FSUIPC 4.40, 4.53, 4.56. I believe the upgrade from 4.40 to 4.53 was the equivalent of a complete reinstall – is that correct? If I start FSX and do not allow FSUIPC to start (“Manaul Load” in dll.xml) the fatal error does not occur during flight. But then, when I select “End Flight” and try to close FSX I get the same “fatal error” message and the same appcrash data. I do not think this is an FSUIPC error but who knows more about controls.dll that the FSUIPC developer? VISTA32/SP2 HomePremium Edition Intel E6600 / eVGA 8800 GTS / 4 GB memory No other software runs on the system – not even security or firewall Here is the VISTA app crash data: Product Microsoft® Flight Simulator X Problem Stopped working Date 10/29/2009 1:01 PM Status Not Reported Problem signature Problem Event Name: APPCRASH Application Name: fsx.exe Application Version: 10.0.61637.0 Application Timestamp: 46fadb14 Fault Module Name: controls.dll Fault Module Version: 10.0.61637.0 Fault Module Timestamp: 46fadb57 Exception Code: c0000005 Exception Offset: 000187f6 OS Version: 6.0.6002.2.2.0.768.3 Locale ID: 1033 Extra information about the problem LCID: 1033 I see identical data every time FSX crashes with a fatal error. The fatal error is 100% repeatable when I start a FSUIPC saved flight that previously suffered the fatal error - even after a VISTA reboot. The same error occurs at exactly the same spot in the flight no matter what aircraft I use. Sometimes the error will not occur if I restart the flight with very low settings for most sliders, in other situations the fatal error will occur every time, even with all sliders set to minimum. The problem only seems to occur flying near airports where I am using flaps, landing gear, tuning radios etc. For example on an approach to KSAN the error occurs every time I hit G to lower the gear. On an approach to KPAE the error occurs every time I lower the flaps or adjust the prop pitch. I flew the stock KingAir 350 from Tacoma to San Diego non-stop with no errors. I did a lot of altitude changes, heading changes for different waypoints, lots of changes to engine controls, autopilots, lights with no fatal errors. As soon as I got to the FAF for KSAN LOC 27 and lowered the landing gear – “fatal error” Control.dll properties shows 26/09/2007 4:08 PM File Version 10.0.61637.0 File Size 238KB Here is the FSUIPC log from an inflight crash: ********* FSUIPC4, Version 4.546 by Pete Dowson ********* Reading options from "F:\Program Files\Microsoft Games\Microsoft Flight Simulator X\Modules\FSUIPC4.ini" User Name="Jerald King" User Addr="**** (I hid this here ******p" FSUIPC4 Key is provided WIDEFS7 not user registered, or expired Running inside FSX on Windows Vista (using SimConnect Acc/SP2 Oct07) Module base=61000000 Wind smoothing fix is fully installed DebugStatus=15 16 System time = 29/10/2009 12:57:15 16 FLT UNC path = "C:\Users\Administrator\Documents\Flight Simulator X Files\" 16 FS UNC path = "F:\Program Files\Microsoft Games\Microsoft Flight Simulator X\" 749 LogOptions=00000000 00000001 749 SimConnect_Open succeeded: waiting to check version okay 7629 Running in "Microsoft Flight Simulator X", Version: 10.0.61637.0 (SimConnect: 10.0.61259.0) 7629 Initialising SimConnect data requests now 7629 FSUIPC Menu entry added 7738 c:\users\administrator\documents\flight simulator x files\Bronco at KTIW - NO scenary.FLT 7738 F:\Program Files\Microsoft Games\Microsoft Flight Simulator X\SimObjects\Airplanes\OV-10A_FSX\OV-10A.AIR 27628 Weather Mode now = Theme 27628 C:\Users\Administrator\AppData\Roaming\Microsoft\FSX\Previous flight.FLT 49031 F:\Program Files\Microsoft Games\Microsoft Flight Simulator X\SimObjects\Airplanes\Carenado mooney\Mooney_Carenado.AIR 49031 c:\users\administrator\documents\flight simulator x files\AutoSave Thu 124238.FLT 50092 System time = 29/10/2009 12:58:05, Simulator time = 13:10:25 (21:10Z) 50092 Aircraft="Mooney M20J Red Wine" 88344 Advanced Weather Interface Enabled 249368 Sim stopped: average frame rate for last 164 secs = 19.8 fps 260163 F:\Program Files\Microsoft Games\Microsoft Flight Simulator X\SimObjects\Airplanes\Mooney_Bravo\Mooney_Bravo.AIR 261037 Aircraft="Mooney Bravo" On the 16th I installed Carenado’s Skylane II RG 182 for FSX and the SAAB freeware Scandia for FSX that I downloaded. I have uninstalled the two airplanes (using their uninstallers) but the problem remains. My VISTA update log shows no systems maintenance applied between Oct 15 and October 19. I ran FSX for several hours on the 15th AFTER the maintenance was applied and had no FSX problems. Can you suggest anything I might do to resolve this problem?
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.