CG formula anyone ?
 

Does anyone know if there is a generic formula to calculate an aircrafts CG ? this is with reference to 3 weights i.e. Take off CG , ZeroFuel CG and Landing CG with the CG's expressed in terms of % of MAC

I'm not sure what you mean by a formula. It's pretty simple. It's just a matter of mass times distance.

The aircraft has a Dry Operating Weight and a Dry Operating Index reference to a fixed datum. Each item loaded then has a moment which is its mass times its distance from the datum.

After everything is loaded you have a total mass and a total moment. Divide the moment by the mass and you have the CG expressed as a distance from the datum. Find out where that is, divide it's distance from the mean leading edge by the mean chord and you have a % MAC

To determine MAC ZFW, simply leave the fuel out of the equation, and for landing use takeoff fuel- trip fuel.

Simple!!

('Course, all I do is sign the Computer Load-sheet!!):E

cg
 

Wiz thanks for the nice explanatory reply , its making more sense to me now , actually i'm in the process of writing some code for a loadsheet as a personal project (amateur programmer).I have the moments in the form of indices and the total effect as an index , i have all the weights too,what i dont have is the mean leading edge and chord . I'll try and get that info now

quote "Find out where that is, divide it's distance from the mean leading edge by the mean chord and you have a % MAC" unquote

i have the distance effect in terms of indices , i suppose....i need to get the mean leading edge now ? can you explain what you said ( quotes) ? that would be great

edit : what parameters do i need besides the ones i have

Super,

I'll try!!

As you say, you have a series of indicies. These are reference a particular datum. By dividing your total index (sum of all indicies, which will be in the form of KGM, Foot-pounds or whatever system you are using) by your all up weight, you end up with a distance. This is the CG as a distance from the datum. You therefore meed to know where the datum is (it is typically, but not exclusivley, the nose of the aircraft.). This will almost certainly (no, make that CERTAINLY for any conventional aircraft) fall somewhere on the wing.

MAC is simply the avegage chord. For a constant chord wing, it IS the chord. For a constant taper wing, it is simply the average of the root and the tip chord. Sweep back makes it a little challenging, but draw a couple of wings and a graphical solution will become obvious.

If the CG you've just established falls 1/3rd of the way back from the front of this mean chord, your %MAC is 33%. If it's half way, it's 50% and so fourth.

Typical ball-park figures for a jet transport would be 10-40% MAC.

So, the parameters you need are Zero Fuel Weight, Zero Fuel index, index for each loading zone, index for fuel, and position of the leading and trailing edge of the MAC reference the Datum.

Hope that helps!!

excellent info thanks again Wiz , yes i'll have to get the chord details , i have my script giving me the ZFW and LIZFW , TOW and Index and LAW and index , i've just applied a script to do what the manual loadsheet does, its for an Airbus A310F ,i have the DOW and DOI etc in a database and the deadload is calculated by the script , when i decided to depict the graph is when i came to this hurdle , about the datum ..yes in this case it is 6.3825 meters forward of the nose and there is a reference point to get the +ve and -ve moments,i'll look to get the chord info now....thanks for your help..will post again to follow up this thread

I have the moments in the form of indices

Why bother ? .. if you are doing the sums on a PC, stay in moment .. using IU just adds calculations for the sake of adding calculations and certainly gives no benefit along the way. I've not done any load work on Airbus but I can't imagine that they would do things differently .. then again .. ?


By dividing your total index (sum of all indicies, which will be in the form of KGM, Foot-pounds or whatever system you are using) by your all up weight, you end up with a distance.

Suggest that either

CG = total moment/total weight, or

CG = (total index * index constant)/total weight


You therefore meed to know where the datum is

Very true. Generally the FS datum is near, or forward of, the nose .. such a bore .. negative numbers. For graphical loading system work, it is more usual to see the (trim) datum somewhere inside the CG envelope.


MAC is simply the average chord

Not quite .. MAC gives a theoretical wing with similar aerodynamic properties

Thanks John!

Super, you'll find that when recieving contrary information, "Listen to John Tullamarine" is a pretty safe bet!

Thanks for the replies

Why bother ? .. if you are doing the sums on a PC, stay in moment

its not really a bother (thats the form i have the data in) , to clarify.....i am taking this info from a physical manual loadsheet , thats why i have the indices which is infact better for me since i have to show index units on the loadsheet anyway , however i do know that the reduction factor (index constant) is 1000 , the datum is 6.3825 meters forward of the nose and Kgs/in is what is being used...i have the CG bit so far..and i understand that in this case it would be in inches ..which again brings me to MAC ?? .......

here's some data from a computer loadsheet for the same aircraft type

LIZFW -4.59 MACZFW 24.21 ZFW = 100278 KGS
LITOW -31.60 MACTOW 21.16 TOW = 141278 KGS
LILAW 4.47 MACLAW 25.68 LAW = 112578 KGS

given the above data , and the mentioned datum and index constant
to get any MAC = ??

i am taking this info from a physical manual loadsheet

suggest that you get a copy of the TCDS, the AFM and reverse engineer the trimsheet to figure out the actual numbers .. quite easy to do once you get into it .. and then set up a normal calculation for the PC. Trying to make a trimsheet directly into something else is a recipe for ulcers and frustration.

the datum is 6.3825 meters forward of the nose

if you have such a datum for the trimsheet, forget the exercise ... the trimsheet will be a dog's breakfast so far as (in)accuracy is concerned. More likely, the basic OEM FS datum is forward of the nose .. but the trimsheet uses a more appropriate trim datum (located somewhere in the envelope) .. you can tell if this is the case by the shape of the envelope on the trimsheet .. if it's long and skinny and slopes from lower left to upper right .. then the datum is somewhere out the front (and whoever designed the trimsheet really doesn't know what he was doing) ... if it's sort of squarish and boxy .. the (trim) datum is in the envelope. I've not played with Airbus but I could not imagine that anyone in his/her right mind would have designed a trimsheet using the FS datum.

MAC overlay

the only reason for you to worry about MAC is if your operator prefers to use MAC to describe CG and (as would be the case) the loaded CG/flap defines stab setting for takeoff. If the present trimsheet has a CG (or MAC) overlay, you can reverse engineer this in a doddle as part of the larger exercise.

Why don't you scan and email a copy of your trimsheet or post it somewhere and we can offer specific advice ?


(Logarithms don't come into it at any stage ...)

That is the datum given to us in our manual and there is a reference point as i mentioned earlier , the trimsheet looks like any other trimsheet i have prepared for many airlines with a slight difference in that this has indices for the deadload instead of the scales to trim the deadloads , i will definitely scan the trim chart since i dont have the knowledge to ellaborate further

as far as the exercise is concerned it is definitely no waste of time or dogs breakfast as you put it since it is only a script which actually greatly simplfies (so far) with 100% accuracy that which is being done manually and seems to be working , all the airlines i've dealt with so far have used MAC on their loadsheets and MAC to determine the T/O stab trim settings so i wouldnt know the difference,but i'll do the scan first

We look forward to seeing the picture ....

That is the datum given to us in our manual

Invariably, manuals give the OEM FS datum ... if the OEM suggests a trim datum (as most of the larger crowds do) generally it is hidden away in a Weight and Balance Manual somewhere. Nevertheless, the appearance (shape) of the envelope on the trimsheet gives the secret away in a glance ...

indices for the deadload instead of the scales to trim the deadloads

Presumably, this means that you don't have a "normal" trimsheet presentation .. and that the IU sums are done by tabulation and the answers transferred to the envelope ? .. a bit like a GAMA loading system calculation ?

definitely no waste of time or dogs breakfast

.. some elaboration .. my comment related only to extracting the base data from the trimsheet by reverse engineering the picture .. if the datum is the FS datum, then the sheet will be very coarse in its accuracy and the said extraction of underlying numbers becomes a tad more problematic .. if a sensible trim datum is used, the numbers usually fall out with a few minutes "back of a fag packet" calculations.

a script which actually greatly simplfies (so far) with 100% accuracy

Many of us who practise in the weight control arena avoid PC simulations like the plague due to the need for a LOT of error checking routines, etc. .. do be careful with your work ...

MAC to determine the T/O stab trim settings

Very conventional practice.

When you post the picture, we can help with the reverse engineering .. my interest is to help you get the thing correct .. far too many folk play with trim sheets and end up with all sorts of strange results ...

sorry! Opened the wrong window.

I'm confused. How does changing the datum affect accuracy? It's just a reference point.

How does changing the datum affect accuracy?

Therein lies a (pretty obvious, if you think about it) secret of good trimsheet (in fact, any graphical system) design.

For a longhand (or PC) calculation, for all reasonable purposes, datum position doesn't matter an iota. However, that is not the case when it comes to drawing pictures ...

Consider the datum position -

(a) if a long way forward of the envelope, the envelope graph will be long and thin and stretch from lower left to upper right - typical GAMA POH style which, in turn, is based on an ICAO sampler

(b) if somewhere inside (or near) the envelope, the envelope will be squarish and boxy in shape

(c) if a long way aft of the envelope, it will be like (a) but sloping from lower right to upper left - can't imagine that anyone would bother doing this

Now ..

(d) if you are not convinced that this is the case, take your favourite aircraft's AFM and rework the CG envelope (weight by moment) for such datum positions ... then plot the co-ordinates.

(e) without running any sort of error analysis, consider the way one can scale the envelope variations ... and the resulting physical chart dimensions.

(f) in case (a) one might have, say, 10 inches of CG travel (forward to aft limit ... represented as moment) drawn with a dimension of, say, half inch, between forward and aft limits ... simply because you have to fit in the sloping characteristic on the page

(g) in case (b) the slopey bit goes out of consideration and you can stretch the envelope laterally so that, say, the 10 inches might be scaled to fit on, say, 5 inches of paper

(h) when completing a trimsheet, which of (a) and (b) would you reckon might give you the more accurate answer ? (where "more accurate" = "lesser error")

(i) re (b), the designer ends up having to be careful that he/she doesn't go overboard and make the scale too generous.


As this thread develops we may end up doing a critique on whatever sheet the originator has in mind .. and all will become patently clear.

Hmm. Still not quite getting it, but I'm unfamiliar with a trimsheet. I'm not an operator, just an engineer working for the OEMs, so I've always been happy with our "slopey" charts. I'd like to see an example if you have one.

If you have slopey charts, then your folk may need to have a beer and reconsider what they are trying to do. If the envelope is not boxy then the sheet is not as good as it could be ...

In general, the slopey charts are the province of the GAMA fraternity (largely because the GAMA standard format follows the ICAO recommended practice .. ie both are a bit silly when it comes to loading systems). The heavy metal brigade generally use a more suitable trim datum for trimsheet design. There's naught difficult or fancy about this stuff .. all quite straightforward once you get the hang of it.

Quite happy to send you a sample sheet (for my sins I have done more than a lot of these little joys) ... do email me and we can discuss offline ... engineer to engineer ...

graph
 

OK i've uploaded the chart http://losheet.bravehost.com/losheet.jpg
clicking on the link directly wont work , please copy and paste the URL

the reference point i've mentioned earlier is 26.67 metres from the Datum which is 6.3825 metres forward of the nose ( added that info in case needed by you)

Thanks for the scan ... now we're cooking with gas ...

(a) bit late in the evening to do much tonight but will have a look in more detail tomorrow during the odd coffee break at work

(b) presuming that the A310F has a US TC the TCDS will give me most of the info I need .. any other stuff I will post for you to provide

(c) now clear that you are working not with a trimsheet but a (presumably) tabular system for doing the loading sums (which is all the normal trimsheet trimlines do) and then you transfer the total moments (IU) and weights to the envelope to check if the loading is OK

(d) the loading system envelope appears to be well designed. Notice that, with a bit of imagination, you can describe the envelope as being sort of squarish and boxy ... rather than being like the typical envelope one sees in a GAMA style light aircraft POH.

(e) your "reference point" is almost certainly the loading system datum (which is most usually referred to as a "trim datum" .. doesn't matter what you call it, of course)

(f) the loading system datum is 25% MAC which you can tell by a quick look at the envelope .. how ? .. that CG line is vertical ... at the datum the arm is zero so any weight x arm calculation must give a zero moment (and, in this case, IU)..

(g) the designer appears to have done a conventional error analysis for the load calculations


Now, I presume that what you are looking to end up with is the IU equation for this loading system ? (If not, do describe your goal in a bit more detail).

The IU equation, for just about any system, has the general form

IU = A + ((FS - trim datum) * weight)/B

(you might have some unit conversion constants stuck here and there as well but the form doesn't change ...)

where

IU = index units

A = a constant IU to get rid of the minus numbers on the IU scale. For your system, A=0. If you wanted to get rid of the negatives, you might put A=80 (depending on how long a scale you want to draw ... you only need to make it cover the likely range of entry IU values). If you used 80, then -80 on the scale would become 0, -70 would become 10 and so on.

FS = the (fuselage) station of interest (typically where a load is positioned). In your case, FS will be measured from the main datum (6.3825 m fwd of the nose).

trim datum = a convenient and useful FS value which gives you a suitably shaped CG envelope when drawn wt x IU. It appears that, in your case, this value is 26.67

Note that (FS-trim datum) gives you a revised arm measured from the trim datum rather than from the main FS datum .. no more, no less.

weight = is the weight located at the FS of interest

B = the non-dimensionalising constant moment used to convert the basic moment (=wt*arm) to an IU. You suggested that this value is 1000 .. we can check this out in due course as part of the reverse engineering exercise

Note that, if we put A=0 and don't use a trim datum (put trim datum = 0 .. ie the trim datum is at the FS datum) then the general equation becomes

IU = (FS * wt)/constant

which is the usual

IU = moment/constant

basic formula with which we are all familiar.

Free online calculator (not tried it myself but it looks funky)...

http://adamone.rchomepage.com/cg_calc.htm

http://www.geistware.com/rcmodeling/cg_super_calc.htm

great explanation :ok: thanks , :ooh:(ooh) the ball is back in my court ,hmm lemme see hope i get racket to ball at least :O... here goes.......

(c) now clear that you are working not with a trimsheet but a (presumably) tabular system for doing the loading sums (which is all the normal trimsheet trimlines do) and then you transfer the total moments (IU) and weights to the envelope to check if the loading is OK

yes thats it , i have all the index units in tabular form on the manual loadsheet itself for each ULD(unit load device) position ,i.e. in effect the station . Had been instructed that the reference point(or trim datum which you explain it is) was created to enable/create -ve & +ve moments for easier calculations instead of -ve moments alone . The IU's i already have in tabular form like you had mentioned , my script only adds them up after given the weights(form inputs by user) for all the ULD positions(stations) . At the end of processing , i have my ZFW/TOW/LAW weights and their respective indices ready for use

Now, I presume that what you are looking to end up with is the IU equation for this loading system ? (If not, do describe your goal in a bit more detail).

yes so the goal is to transfer the weights and IU's i already have(automated) , transfered to the envelope ...so thats what i need ...a method to generate the CG Given the weights and IU's

i could graphically attempt to depict the graph provided i have a method to calculate the CG's by the script .....hope i'm clear

I have all the index units in tabular form

doesn't really matter which way you go .. arithmetic calcs will give a marginally "better" accuracy .. but the difference is not worth worrying about if the trim sheet is well designed .. and at the risk of potentially higher error rate. Overall, my experience suggests that the trimsheet is the better tool...

The best manual system with which I have been involved had

(a) initial trim calculations done by the freight shed folk to run up a conventional IATA style load sheet

(b) flight crew checked using a circular trim sheet (looked a bit like a nav computer). As the weight control engineer for the operator, I was against this initially (due to concerns regarding variable errors across the sheet) until I saw just how effective it was in operations .. captain ran through the can loads and the F/O ran the trim calcs. Very fast and very reliable .. changed my thoughts on the matter.

(c) .. but, if you don't double check that the cans actually get put in the right bays (ie as per the loadsheet) .. it all can become both academic and exciting


the reference point(or trim datum which you explain it is) was created to enable/create -ve & +ve moments for easier calculations

.. total, utter, and complete nonsense. It never ceases to amaze me how folk can dream up innovative ideas such as this. I am bemused that anyone could think that a mix of plus and minus makes for simplicity given that many pilots don't have a particular affinity for such things ?

For aircraft of this class, it is entirely conventional for the OEM to suggest a trim datum in the loading manual/weight and balance manual (or other similar names). No reason, of course, why you should use the OEM's suggestion but it will probably be as good as any alternative in most cases.

The trim datum's sole use is to get a datum position (for a graphical loading system) which will give you the most accurate trimsheet.

As I showed earlier, you can do whatever you want with the entry numbers .. can make all the entry positive, negative, or a mix according to your desires .. positive makes the most sense, though.


a method to generate the CG Given the weights and IU's

too easy .. I'll have a look at the TCDS later on today and (presuming that gives me all the info I need) I'll give you the IU equation for the system you are using and, more importantly, show you how to work it out yourself for the next time .. the equation can then be rearranged to make CG the dependent variable.

You can, quite easily, extend your present system to do the lot on the PC .. just a matter of comparing the CG with the forward and aft limits to determine if the loading is OK or not.

Freighter hacks unite !!

Looking at the TCDS, there is no 310F, as such, although it appears that you have a 300 series aircraft.

Using the generic MAC data in the TCDS notes, the data fits your envelope reasonably well but not quite as closely as I would have expected given that the envelope appears to have been drawn reasonably well.

Could you please advise the following from your OEM manuals, in metres ..

(a) LE MAC

(b) length MAC

and confirm that the presumed trim datum is 26.67 metres precisely ?

John could you have a look at this TCDS
page 54 type 310-304 (variant 1) ? ...it should be the one , 310F's were converted from pax versions ...thx

That was the model I presumed to be your bird.

If you could check your manuals for me, please, to confirm that LEMAC is at 992 inches aft of datum ? I presume that to be the case but sometimes the OEM does cute tricks with plug FS references and I don't have any Airbus data to check for myself.

srry for the late reply ..yes STA 992 is confirmed for LEMAC

MAC is 5.8287 metres long ...typo corrected :}

... I think, perhaps, your quoted MAC is a typo (other than for the Airfix model) .. but thanks for the LEMAC confirmation. The envelope doesn't quite fit the numbers without a bit of massaging and I cannot define where the error is without having access to the remaining data. However, I can give you enough to carry on with ... will put a post with some numbers tonight providing the pub tonight has provision for net access.

Finally back onto this one ...

First, it appears that your suggested trim datum (reference position) of 26.67 m (equivalent to 25.275% MAC) is not quite on the mark. Possibly, you quoted from a company document which, at some time in the past, has had a typo sneak into the story. One of the problems with any imperial/metric conversion is round off and/or conversion factor errors .. just one of the problems with which we have to contend.

Working just with the MAC grid, the most reasonable story for this system is ..

IU = (FS - 26.654) * weight / 1000

where the system is metric .. ie FS in metres, weight in kilogrammes, and moments in kg.m. Note that IU has no dimension and is just a number.

Derivation follows a simple logic of fitting the observations to the standard equation.

The standard equation is

IU = A + (FS - TD) * weight / NDC

where

IU = trimsheet entry IU.

A = a constant IU used to "shift" the entry scale to get rid of negative IU values. Note that A is only relevant to the entry line and envelope and doesn't figure in delta IU calculations for the loading position trim lines. For the present loading system, where the zero IU coincides with the trim datum, A = 0.

FS = loading arm referred to the OEM "standard" datum ie a fuselage station

TD = trim datum. The purpose of using a trim datum is to change the datum for internal loading system calculations. This is only of use for graphical systems and provides the opportunity to give the best graphical execution accuracy. The TD can be seen most easily if the trim sheet has an overlay CG grid. The CG line which is vertical on the sheet is the trim datum position. For the present system, the trim datum is 25% MAC, which corresponds to a fuselage station of 26.654 m.

weight = the weight located at the loading arm, FS

NDC = a non-dimensionalising constant IU, used mainly to make the numbers a bit more manageable . .especially if the system is worked in millimetres ... For this system, NDC = 1000 kg.m

To work out the value of the numbers, read off some MAC co-ordinates as accurately as you can do reasonably.

For my calculations, I imported the chart into a drafting package, squared the scan, and then scaled off the co-ordinates directly. (Note that the chart, while being quite neat in its drawing, is not well drafted as the scale is a bit variable across the sheet).

My read-off IU values were

%MAC______18_______29_______40
FS value__26.246___ 26.887____27.528

weight
150,000___-60.93____35.20____131.29
70,000____-28.70____16.35_____61.46

(apologies for the underscores .. I've forgotten how to script tabs)

Rearranging the standard MAC equation

%MAC = (FS - LEMAC)*100/MAC

gives

FS = (%MAC * MAC/100) + LEMAC

to convert from the known %MAC to the equivalent FS

The FS and weight values can be fed into the system equation

IU = (FS - 26.654) * weight /1000

to come up with calculated IU values.

For the present system, the equation fell out near immediately. Sometimes you will need to play with the calculations a bit until things start to make sense. This is best done in a convenient spreadsheet package. You may need to play a bit with conversions kg/lb and in/ft/m/mm as well as the NDC value until the numbers start to make sense. If there is no CG grid, an indication of the TD will come from consideration of the envelope lines and may require some iteration to get sensible numbers. In any case, the numbers usually fall out within a couple of minutes work ..

Comparing the calculated values to the values read off from the sheet gives "errors" (delta between read and calculated values) in the range -0.1 to +0.3 IU .. ie functionally zero.

If we had used the suggested trim datum of 26,67, the "errors" move to values in the range +1.0 to +2.7 which is a bit strange as there is no central zero tendency in the distribution.

As the TCDS doesn't give any envelope data, I can only look at the MAC grid but I am pretty confident that the equation suggested will fit when you check the envelope against the AFM envelope data.

Thanks for the reply and Great explanation John ....am going to understand and work with the info

Questions via email


(a) calculating %MAC

This is done as a standard pilot-type CG calculation with a final conversion to %MAC

empty a/c_________EW_______ECG_______EM______EIU
load 1
load 2
......
ramp load_________W___________________M_______IU

CG=M/W

If you prefer to work in IU, then this becomes

CG=(IU*IU constant)/W

To convert CG to %MAC

%MAC=(CG-LEMAC)*100/MAC


(b) checking whether CG is inside/outside the envelope

This requires that you know

(i) the forward and aft limits at the weight of interest

(ii) the loaded CG at the weight of interest

The loaded CG is done as in (a) and the limits are worked out from the envelope. Generally easiest to work in CG rather than moment as the lines usually are either constant limit or straight line variations of limit with weight. If the limit is constant, that is the answer for that weight range, if a straight line variation you use the normal equation to work out the limits ..

For a straight line through points (a,b) and (c,d) the standard straight line equation is

y = mx + n

where

m = (d-b)/(c-a)

n = d - mc (or b - ma, as you prefer)

(You replace x and y with whatever variables are on the axes)

For example, the straight line through (1,1) and (4,10) has

m = 3 and n = -2

where

m = (10-1)/(4-1) = 9/3 = 3

n = 10 - 3*4 = 10 - 12 = -2

or

n = 1 - 3*1 = 1 - 3 = -2

If you were to come across an envelope with curved lines, there are plenty of curve fitting routines available on the net to help you out.

(iii) once you have the limits and the CG, it is a simple matter of checking that the CG lies between the two limits at the weight.


90% of the effort goes into the programming (especially error trapping), not working out the basics ...

so...for a ZFW/ZFWI of 78624 kgs / -1.95

CG = (-1.95 * 1000) / 78624 is that correct ?


(ZFW is from 2000 kgs in trim tank , no other weights taken into consideration
just as an example i.e. DOW + 2000 kgs ...)

That's measured from the trim datum .. to get the arm from the main datum (forward of the nose) add 26.654 m. ie ..

(a) measured from the trim datum CG = -0.025 m

(b) measured from the main datum CG = 26.629 m

thx
 

Thanks for the offer to help further , in reply to my mail ....so......
Here's what i have followed so far...what i see is that sometimes at certain weights/indices the CG%MAC numbers which we can read off the Chart seem off by a tiny bit compared to what we can calculate , i'll try and recreate that situation and post the ZFW/ZFWI and the CG and CG%MAC when i stumble upon those numbers again.So from whatever progress we've made with your help in the project..herein lie my first hurdles/challenges , what i had hoped and intended to do (hopeful.... but not too far fetched ??).. is to superimpose a Plot based on x and y .. on a page with the graph serving as a background , x being indices and y the weights both of which my script already derives.
I could always only just print out the calculated CG's and %MAC's which would be a simple solution to the task on hand , but showing the graph is more challenging and its always fun to add some more learning curves .If it is concluded that it is in fact posssible to depict the graph , the question is about how to scale it i.e pixels vs Drafted Chart , i have not yet begun to plot various instances of x and y's with the program to see how far off it is and in which instances so.....assuming that ...we are...(well its not a purely personal project effort now :)) ..able to somehow get the scale right )
so
Limits for the CG%MAC's ....to be honest i have'nt yet understood how to derive those...for a dynamic range of weights and indices that is

First thing to remember is that this stuff is not rocket science by any stretch of the imagination .. just needs a bit of housekeeping to keep the numbers under control ....


the CG%MAC numbers which we can read off the Chart seem off by a tiny bit compared to what we can calculate

The CG (or %MAC) grid is reasonably accurate on this chart .. providing you use the formula as I gave it.

For any of these reverse engineering exercises, there will always be a bit of residual error due to

(a) drafting errors in the chart

(b) reading errors when you are trying to work out what the numbers are against whatever scale you are trying to read


hopeful.... but not too far fetched ??

Stay with it ... there's nothing hard here .. just might take a little while for you to get the hang of what you are doing .. then it all becomes quite easy


x being indices and y the weights

Correct


how to scale it i.e pixels vs Drafted Chart

You will need to be able to program at pixel level .. shouldn't be too hard to find out how to do that on your system.. then it's just a matter of generating a suitable scaling factor .. I haven't needed to do that sort of thing for years ...

Be careful if you are not going to plot point by point .. generally with weight by moment (or IU) loads give straight lines (although the fuel line won't).


Limits for the CG%MAC's

If I follow your concern correctly here .. the AFM will give you a CG envelope .. either FS (or %MAC) against weight. You can convert FS to %MAC (or vice versa) using the standard equations. If you are looking at working out the forward and aft limit at a given weight, the easiest way is to set up equations for the limits from the AFM envelope. Once you have calculated the weight/CG co-ordinate, you can use the weight to calculate the forward and aft limits .. and then test to see if the calculated CG is acceptable or not.


Suggest you work through the problems and pose questions as you need ... my guess is that there will be a few other readers who will maintain an interest in the way one needs to go about this work ....

Yes indeed, gentlemen:ok:

and I did study the flight envelope and I read FAA H8083 1A[ great pilot stuff]--;)


Great stuff JT--como siempre!

SuperNovaSurfer---whacha buidin'?:oh::}


PA

Hello PA ,
am attempting to write some code which in effect would automate what is being done manually for an Airbus A310F loadsheet , the manual load and trimsheet is index based for all the stations on the aircraft,after obtaining the required weights from a table what follows is this graph

http://losheet.bravehost.com/losheet.jpg

where those indices and weights are plotted to check and obtain the CG's and %MAC's , allmost all of the other loadsheets for various aircraft are computerised loadsheets in our company written by professional programmers.

What i am doing is just a purely academic "project" in the process of learning code/programming which happens to be my hobby , the program would in effect(if successful) ....automate the loadsheet ....its just academic as i mentioned ..no intentions or delusions of having it certified for actual use:pummm....(yet)...kidding.

what makes it interesting and challenging for me is that this script is web
based and written in Php...so basically one just inputs the positions and loads ..and the program computes all the required Data

so thats what its about....i'll mail you the link to the webpage if you'd like to see it PA ..

The toughest aspect is only now beginning for me as i've mentioned on the previous posts with JT ... with help from JT with the formula and other explanations , i think i could compute the CG's and print them ou in some common airline format ..but, thats not what i really want ...i am attempting to display the loadsheet graph showing the calculated data ..adequately and correctly plotted ....thats about it...:eek::}

display the loadsheet graph showing the calculated data ..adequately and correctly plotted

reasonably straightforward ..

(a) plot on the weight by index unit chart .. not weight by CG

(b) most (and probably all) loads (other than fuel) will present as straight lines eg seats, cans, etc

(c) fuel will be a complex line and you will need to look at the variation of fuel arm with volume .. if you can scan the relevant pages from the Airbus manual we can talk you through that .. quite easy once you see how to go about it

The only element of difficulty is to find out how to plot at pixel level on your system ... plus the inevitable and painful process of including sufficient error trapping routines to make the software reasonably idiot proof ....

JT i'm mailing you a link showing the graphical display option/program i have as of now for use along with my program ,Dont intend to show the fuel trimming, I intended to adapt the display program for my usage , the link will show another Trim Chart Graph and not the one we are discussing its just to show the idea , notice the difference caused by one generated by the graphic program and the scales on the Scanned chart intended to be used as page background

Trim Datum
 

John ,
workin with a trim Datum of 26.67 is actually giving more accurate numbers e.g.

weight = 95000 kgs , index = -10
FS = -10000/95000 = -0.105263 + 26.67 =26.5647
CG MAC% = (26.5647-25.2132)*100/MAC = 1.35153 *100/5.8287=23.18
which is perfect as seen on the graph
the results match the graph at most combinations of wt/index
tried 140000 and -10 , 140000 and +10 , 140000 and -20 , +20 etc etc

optmum cg
 

OK looks lke the graph's almost done , although not that great a dsplay of graphics I thnk it'll do for now , wll let u know when ts done,workng on the STAB trim setting derivatons.While on the topic of CG s there anything such as optimum CG ?

.. look forward to seeing your work in due course.