Resolving CG issues in FS2004

[Guest]

I have now tested the Fs2004 CG bugs which have been reported to me. I confirm that there is a loaded CG limit bug in FS2004. Please load and use the default FS2004 Mooney for testing at maximum realism.Microsoft obviously wanted to provide some guidance as to how much payload could be placed or removed safely at a particular station. A payload management screen requires explicit declaration of fore and aft CG limits which FDE authors can control even if it the chosen limits are excessively safe. Unfortunately that is not how it works in FS2004. The FS2004 payload manager shows a picture of a tailwheel aircraft for all aircraft and places a current CG locator within a red delimited safe CG box. Unfortunately this means absolutely nothing. The algorithm which runs to decide where to place the CG limits uses only the wing location without any regard to the wheel locations. To test move the two 100lb children in the rear seats of the Mooney to 46.1 feet behind the datum instead of 6.1 in the aircraft.cfg.I doubt 200 lbs @ 46 feet behind datum is a situation that would work safely in a 4 seat GA single. Now look at the changed CG diagram and note that FS2004 estimates that this is well within the Mooney aft CG limit. If you start logically with the Mooney on the ground, as most aircraft do when someone is loading them, it will crash because CG has gone way behind the mainwheels even though the payload screen indicates that you have loaded the aircraft safely.A possible fix which I do *not* recommend is mentioned below to open debate on possible fixes. However I believe only Microsoft can fix this bug. If you switch to the Mooney in flight whilst it is loaded in this way it will be safe and will handle OK. That may be due to a 'CG consequence miscalculation bug' in FS2004. In passing I invite comments on whether you think that the in flight consequences of a very aft CG (as determined by the FDE placement, not the misleading payload screen), is being miscalculated by FS2004 during this Mooney test. On the other hand the 'Empty CG bug' which has been reported to me and elsewhere as a new bug in FS2004 is easily fixable and is not a Microsoft bug. It is an FDE design time bug.In principle the declarations below place datum on the centreline at 25% chord and the second co-locates CG.reference_datum_position=0,0,0empty_weight_CG_position=0,0,0However MSFS cannot process the variable;empty_weight_CG_position=as a stand alone declaration of empty CG.MSFS takes the wing position into account when calculating empty CG, even though it has no relevance.FS2004 does however load and read these variables. Suppose an FDE author declares;reference_datum_position=0,0,0empty_weight_CG_position=0,0,0wing_pos_apex_lon=0This is logically inconsistent. It places CG at 25% chord and then 0% chord at 25% chord. Instead of processing the declared variable for empty CG FS2004 will try to calculate empty CG from all the declared wing data and will produce a false result and then impose it on the simulation. Empty CG will not be at 25% chord in FS2004 even though you declared it to be there. To force FS2004 to place empty CG where it should be the fix is as follows;Declare;reference_datum_position=0,0,0empty_weight_CG_position=0,0,0Now declare a logical wing apex position and a chord.wing_pos_apex_lon=2wing_root_chord=8This places 0% root chord 2 feet in front of datum. 100% root chord is 6 feet behind datum. Empty CG will now be at 25% root chord. The safe CG box in the payload manager will place the safe CG limit lines at +2 and -6 feet from datum.Unfortunately the end user won't be told or shown that numerical information. Possibly because it still means nothing anyway, as -6 is well behind the mainwheels of this nosewheel aircraft, (with under wing wheels), and it will crash if the user lets the CG marker go aft of the mainwheel centres which are not indicated except in the outline which places them at the leading edge.The fact that the majority of users will be loading a nosewheel aircraft whilst Microsoft display a picture of a tailwheel aircraft with the mainwheel centres at 0% chord just helps to confuse the average user who will not understand why their aircraft keeps crashing with an aft payload. They are looking at payload manager diagram which tells them it will work for various reasons.The only way to bring the safe aft CG indication ahead of the mainwheels appears to be to declare a false low chord wing which brings 100% chord in front of the mainwheel centres of a nosewheel aircraft. The converse applies to the tailwheel case of course. I do not recommend this.BEWARE - what FS 2004 does with the wing chord data entered here in terms of aspect ratio and stability is as yet an unknown. Entering the value of Mean Aerodynamic Chord into the wing_root_chord= variable to be on the safe side is not a problem since the payload screen will make no sensible use of the data anyway. Just make sure you have placed CG where it should be in relation to datum regardless of whether you use root chord or MAC. Do FDE authors agree that MSFS makes use of this declared chord as an aerodynamic variable and not just as a CG variable? I have only given exemplar values for the four variables used to calculate CG in MSFS. You must interpolate for the aircraft you are making. Any four values which are mathematically compatible will work as far as I can tell. However if the values in these FDE variables have a logical error then a false empty CG will be estimated and will override the declared value in empty_weight_CG_position= . Many FDE have a logical error within the four declared variables. They have to be logically consistent, but they do not have to be truthful. Substitution of MAC for root chord may turn out to be beneficial (or not). By manipulating the four variables whilst retaining logical content you can preserve any necessary aerodynamic content and force MSFS to put empty CG where you want it by prior calculation. I did not bother to test whether station_load variables in FS2004 also require logical wing chord and apex declarations to be processed correctly by FS2004 since any such 'bug' will also be fixed by the means above.As many of you know this 'empty_CG bug' was also present in FS2002. I explain the fix here in detail because it is being reported by some users as a new FS2004 bug and because logical manipulation of the chord variable relates directly to the new (no wheel location reference) bug which generates the wrongly displayed CG limits discussed at the top of this post.--FSAviator

[Guest]

Am I correct then in assuming that MSFS assumes that the reference datum is always at 25% chord? This would seem to be the indication from what you have said.As pertains to the incorrectly displayed CG loading screen, the logical "fix" would be to instruct the end user to ignore the displayed CG limits and calculate thier own.

[Guest]

>Am I correct then in assuming that MSFS assumes that the>reference datum is always at 25% chord? This would seem to be>the indication from what you have said.The SDK stipulates this for the Reference Datum:"Offset (in feet) of the aircraft's reference datum from the standard Flight Simulator center point, which is on the centerline

[Guest]

Bill has explained the MS default versus aircraft designer's choice and the real world situation in detail. Solving the problem for the end user is possible but more complicated. Few would understand or make the effort to calculate change of CG even if the formula was provided in a read me. The safe limit in the real world is unlikely to match the safe limit in FS2002/4.Third party freeware load managers can easily be programmed to provide the data. They could easily take wheel placement into account by reading the contact points data. However they cannot readily calculate whether the aircraft will have acceptable 'handling' in the air. It is probably possible, but certainly very complicated, and would stretch our collective understanding of how the stability, damping, inertia and control derivatives in this product work. In FS2002 the bugged AP might not cope under circumstances where a human could. Most of the' AP bugs' have been patched in FS2004 and AP capability may no longer be a separate issue. However the ability of the AP to process the necessary feedback loops is always going to be degraded by selection of accelerated time and to some extent low frame rates. Working out what is a 'safe' fore and aft limit for CG in a flight simulator is very complex.I believe it should not be attempted. Encouraging any user to vary the ramp weight of the aircraft in a flight simulator with a payload manager is a very good idea. Allowing the average user to move CG without any idea whether it will be safe is not. Fortunately there is a sure fire fix for the awful payload screen in FS2004. Unfortunately for some FDE authors and some experienced users it is a controversial fix. I will try to explain.FDE authors can enable the ability to alter payload weight and disable the ability to move CG in FS2002/4 at will.The 'prevent CG shift' fix is accomplished simply by placing all of the load at the same location as empty_CG. The end user can then vary payload weight to their heart's content, using the faulty payload manager, third party load managers, or editing the masses in aircraft.cfg without danger of moving CG. The controversy arises from a little known FDE bug in FS2002 which as far as I can tell has not been patched in FS2004. This is the 'distributed payload MOI bug'. The FS2002 container SDK asserted that if the aircraft designer took the trouble to create many load_station variables FS2002 would use those variables to recalculate MOI in each axis based on load distribution. Some 18 months ago we discovered that these variables were missing from the MOI equations. This bug was put forward for testing, verified and its effects quantified. No third party fix was possible. As you know Microsoft refused to patch FS2002 for this and other bugs. More to the point they refused to amend the container SDK. Many FDE authors have therefore continued to include many station_load variables within their FDE believing that distributing the load has some effect. Since we proved more than a year ago that the variables are missing from the MOI equations and are not processed this is not true. The load may as well be placed as a single station_load at its centre of mass.However the station load variables are processed by the loaded CG equation. Their effect on loaded CG is probably miscalculated unless the wing data is internally consistent (see first post). Many FDE authors however like to provide experienced users with the ability to empty and fill individual seats to create CG imbalances and so they include distributed loads at many load_stations solely for that purpose. Experienced users were likely to edit aircraft.cfg load_stations in a 'realistic' way.The average user was very unlikely to change the station loads by editing the aircraft.cfg, but is now encouraged to do so via a payload manger which delivers false safety cues. FDE authors may now wish to review their original choice and decide whether to consolidate the load in FS2004 updates to prevent the average user moving CG and crashing the aircraft.Whether that is controversial depends in large measure on the existence of the 'distributed payload MOI bug' in FS2004.This may be tested as follows;1) Note the weight of the load2) Remove all the load stations3) Place all the load at empty CG4) Hand fly the aircraft to asses (inertia) handling in pitch. 5) Divide the original load by two6) Place half 2000 feet in front of empty CG and half 2000 feet behind empty CG7) Repeat the hand flown test and asses (inertia) handling in pitch.Step 6 leaves weight and CG where they were with a consolidated load but the 4000 foot distribution will create huge pitch inertia if the variables can be processed by the pitch MOI equation in FS2004. When hand flown a difference in the pitch inertia of the aircraft would be evident. When I test I find no variation of pitch inertia and conclude that the 'distributed payload MOI bug' is present in FS2004. Note that the fuel variables are processed correctly by the MOI equations so you can repeat the test by replacing payload with fuel tanks and fuel of the same mass. You will then see what would happen if the MOI equations could process station_load variables as the FS2002 container SDK asserts.Test for spanwise distribution and roll inertia if you prefer. You may find changes easier to detect.Since FS2002/4 fuel variables are processed by the MOI equations FDE authors will normally wish to place fuel tank mass centroids carefully, if not accurately, to control, or preserve, their distributed MOI effects. However if the need arises they can all be placed at empty_CG leaving the user with no ability to move CG at all. This would be far more controversial and I do not recommend this.In post one I invited FDE authors to test whether there was an unidentified 'CG shift consequence' bug in FS2004 using the very aft loaded Mooney. Having now explained the 'distributed payload MOI bug' I will suggest that the reason that the load used for the test in post one would be dangerous in flight in the real world, but is safe in flight in FS2004 is solely due to the dangerously aft payload MOI not being processed by the MOI equations. I conclude that there is no additional CG bug in FS2004 and that the observed deviation from real world flight behaviour under aft load conditions may be attributed solely to the 'distributed payload MOI bug'.If you agree that this bug exists then distributing the payload serves little useful purpose and the 'prevent CG shift' fix explained above has much to recommend it since in combination with the FDE bug fix in post 1 it resolves all CG location and control issues in FS2002/4 .--FSAviator

[Guest Ron Freimuth]

In fact, what appear to be CG limits (at LE and TE of wing) are not. The CG limits are not shown in the FS9 loading diagram. However, the location of the CG symbol appears to be correct. Typically between the second and third lines back from the LE. Which would be 25%. Note the main wheels are typically 75% of the MAC back from the LE. In the Mooney, they appear to be near 60% of the way back. CG limits are typically 15 to 35% MAC. Note if MAC is 5 ft, that is a range of 20% of 5 = 1 ft. Many SEL's have limits that range over only six inches or so. Clearly, the empty CG has to be correct or the loaded CG will be far outside the limits. I tried moving the empty_cg in the FS9 Mooney. It appears I had to reload with the Aircraft menu, just as in FS2K2, to effect the empty_cg change. Using the Shft-Ctl_R I assigned for 'reload AC' had no effect in runway pitch, but the former reload did. So, we don't know when the 'old' Reload should be used, or the new one we assign to the KB. I forgot if the CG symbol changed with my changes to the empty_cg. It should, and Percent CG certainly does in FS2K2. BTW, I installed Herve's new LeanIt app and see the Mooney only develops 240 HP or so. The menu spec says '270 HP'. Typical of MS, they don't even get HP set correctly. Ron

[Guest]

As I suspected, and explains with perfect clarity why certain aircraft -- which were stable in FS2002 -- crashed due to stability and CG problems in FS9 before being tweaked for that sim. Once these variables are properly set up, the CG problems vanish.

[Guest]

Makes perfect sense.If individual station loads have NO effect whatsoever on dynamic calculations of the MOIs, then one may as well place the entire payload at the CG. Even simpler, just include the payload weight in the aircraft's ramp weight in the aircraft.cfg file and forget payload handling unless it is an aircraft where payload management is part of the simulation.This is especially true in view of the fact that standard procedure is to adjust the CG position back to a 25% MAC reading once all station loads are in place. That's a pointless exercise; might as well put a single station load at the CG, the effect is the same and it's much quicker and there is no reason to adjust the CG.Problem is, some more experienced simmers who've not read this thread or come to the conclusion on their own may expect to see individual station loads where the pilot and crew/passengers would be, and would feel that "realism" was compromised if they reviewed the aircraft.cfg file and found it had been set up this way. Of course, a remark in the config file would explain the procedure.

[Guest]

>This is especially true in view of the fact that standard>procedure is to adjust the CG position back to a 25% MAC>reading once all station loads are in place. That's a>pointless exercise; might as well put a single station load at>the CG, the effect is the same and it's much quicker and there>is no reason to adjust the CG.I don't subscribe to this non-solution. Payload management is more than simply balance, but also is an integral part of meeting mission requirements.It is a trivial matter to creat as many "station loads" as you like, and even "name" them, providing the locations are all either coincident with, or very close to the CG point.This will at least allow the sim pilot to have some active role in setting up the mission profile, even though it's incomplete.I set up the 400A, Premier and 400XP models with their "typical compliment" of pilots (only one in the Premier!), three passengers and luggage.If the mission calls for more passengers or cargo, then - just as in real life - the fuel load is reduced and the shorter range of the a/c before refueling is a consequence.We needn't throw the baby out with the bathwater! :)BillAVSIM OmbudsmanFounder and Director,Creative Recycling of Aircraft Partshttp://catholic-hymns.com/frbill/FS2002/images/fartslogo.jpg

[skrillah83 0]

ok guys in simpler terms how to get planes back into CG

[n4gix 4,947]

You do realize that this is a ten year old thread, right? Most of the folks in that discussion are long gone from here...

[safioso 0]

hahaha old but gold XD