supernova.surfer

2nd Jun 2008, 13:03

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

View Full Version : CG formula anyone ?

supernova.surfer

2nd Jun 2008, 13:03

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

Wizofoz

2nd Jun 2008, 13:37

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

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

supernova.surfer

2nd Jun 2008, 14:16

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

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

Wizofoz

2nd Jun 2008, 15:10

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!!

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!!

supernova.surfer

2nd Jun 2008, 19:45

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

john_tullamarine

2nd Jun 2008, 23:17

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

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

Wizofoz

3rd Jun 2008, 07:38

Thanks John!

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

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

supernova.surfer

3rd Jun 2008, 15:08

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 = ??

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 = ??

john_tullamarine

4th Jun 2008, 03:11

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 ...)

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 ...)

supernova.surfer

4th Jun 2008, 12:13

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

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

john_tullamarine

4th Jun 2008, 22:19

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 ...

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 ...

rubik101

5th Jun 2008, 15:52

sorry! Opened the wrong window.

gr8shandini

5th Jun 2008, 17:27

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

john_tullamarine

5th Jun 2008, 21:00

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.

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.

gr8shandini

5th Jun 2008, 22:55

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.

john_tullamarine

5th Jun 2008, 23:24

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 ...

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 ...

supernova.surfer

6th Jun 2008, 10:06

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)

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)

john_tullamarine

6th Jun 2008, 13:34

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.

(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.

cwatters

6th Jun 2008, 14:27

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

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

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

supernova.surfer

6th Jun 2008, 15:51

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

(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

john_tullamarine

7th Jun 2008, 01:37

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 !!

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 !!

john_tullamarine

7th Jun 2008, 06:00

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 ?

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 ?

supernova.surfer

7th Jun 2008, 07:37

John could you have a look at this TCDS (http://www.airweb.faa.gov/Regulatory_and_Guidance_Library%5CrgMakeModel.nsf/0/3EAA49F060F00CBB862572AB0056CEA3?OpenDocument)

page 54 type 310-304 (variant 1) ? ...it should be the one , 310F's were converted from pax versions ...thx

page 54 type 310-304 (variant 1) ? ...it should be the one , 310F's were converted from pax versions ...thx

john_tullamarine

7th Jun 2008, 08:18

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.

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.

supernova.surfer

9th Jun 2008, 13:27

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

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

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

john_tullamarine

10th Jun 2008, 01:42

... 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.

john_tullamarine

15th Jun 2008, 13:17

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.

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.

supernova.surfer

15th Jun 2008, 17:06

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

john_tullamarine

16th Jun 2008, 00:46

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 ...

(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 ...

supernova.surfer

16th Jun 2008, 05:39

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 ...)

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 ...)

john_tullamarine

16th Jun 2008, 09:20

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

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

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

supernova.surfer

17th Jun 2008, 11:47

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

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

john_tullamarine

17th Jun 2008, 12:15

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 ....

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 ....

Pugilistic Animus

18th Jun 2008, 02:36

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

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

supernova.surfer

18th Jun 2008, 11:39

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::}

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::}

john_tullamarine

18th Jun 2008, 23:21

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 ....

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 ....

supernova.surfer

19th Jun 2008, 04:32

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

supernova.surfer

22nd Jun 2008, 09:42

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

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

supernova.surfer

24th Jun 2008, 07:54

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 ?

john_tullamarine

24th Jun 2008, 23:59

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

supernova.surfer

25th Jun 2008, 11:28

yup John ..will message you when i'm done getting rid of some bugs thx

QAYS

28th Feb 2009, 21:03

Hello,

In first time, my appologize for my poor english.

I am french And I search formula about % Mac.

i find this formula :

% MAC = 100* C*(LIZFW - K) /(ZFW*Chord) +

100*(Harm- Harm25%)/Chord

For A320 Aircraft:

C = 1000

K= 50

Chord=4,1935m

Harm=17,8015m

Harm25%=18,850m

But this formula is good in some case and false in other, some examples

AirCraftA320A330A320A320A320A320A320

Chord4,19357,274,19354,19354,19354,19354,1935

ZFI27,6112,828,1363,5530,6149,652,4

ZFW479301582635402956006553045462156870

K501005050505050

C1000250010001000100010001000

Harm17,801531,3417,801517,801517,801517,801517,8015

H2518,8533,1618,8518,8518,8518,8518,85%Mac Compute13,827,815,330,7716,6424,8226,00real

Value in loadsheet28,327,830,1730,7735,623235,6

Have you got an explication for this differences

Thank you

best regards

In first time, my appologize for my poor english.

I am french And I search formula about % Mac.

i find this formula :

% MAC = 100* C*(LIZFW - K) /(ZFW*Chord) +

100*(Harm- Harm25%)/Chord

For A320 Aircraft:

C = 1000

K= 50

Chord=4,1935m

Harm=17,8015m

Harm25%=18,850m

But this formula is good in some case and false in other, some examples

AirCraftA320A330A320A320A320A320A320

Chord4,19357,274,19354,19354,19354,19354,1935

ZFI27,6112,828,1363,5530,6149,652,4

ZFW479301582635402956006553045462156870

K501005050505050

C1000250010001000100010001000

Harm17,801531,3417,801517,801517,801517,801517,8015

H2518,8533,1618,8518,8518,8518,8518,85%Mac Compute13,827,815,330,7716,6424,8226,00real

Value in loadsheet28,327,830,1730,7735,623235,6

Have you got an explication for this differences

Thank you

best regards

john_tullamarine

1st Mar 2009, 02:10

QAYS,

Good to have you on board .. don't worry about your English .. your English is far, far better than my long-forgotten schoolboy French.

You have posted an unusually complicated formula for %MAC. I think that we need some more information before we can make some sense of it. Can you advise what the following terms are (ie what do they mean in physical terms) ?

(a) C

(b) LIZFW

(c) K

(d) Chord (ie which particular chord ?)

(e) Harm (perhaps distance from OEM FS datum to CG location ?)

We could run some reverse engineering to relate it to the standard equation but, if you can provide the above information, it will save some time. Indeed, without the information, we can't even begin with a dimensional check of the equation.

regards,

John

Good to have you on board .. don't worry about your English .. your English is far, far better than my long-forgotten schoolboy French.

You have posted an unusually complicated formula for %MAC. I think that we need some more information before we can make some sense of it. Can you advise what the following terms are (ie what do they mean in physical terms) ?

(a) C

(b) LIZFW

(c) K

(d) Chord (ie which particular chord ?)

(e) Harm (perhaps distance from OEM FS datum to CG location ?)

We could run some reverse engineering to relate it to the standard equation but, if you can provide the above information, it will save some time. Indeed, without the information, we can't even begin with a dimensional check of the equation.

regards,

John

QAYS

1st Mar 2009, 08:59

hello an thank you,

Sorry for this equation, in fact i found it on page 124 from airbus document "Getting_To_Grips_With_Weight_and_Balance", I will be back with more explanation

Sorry for this equation, in fact i found it on page 124 from airbus document "Getting_To_Grips_With_Weight_and_Balance", I will be back with more explanation

QAYS

1st Mar 2009, 09:48

hello I am back with more explanation :

Note : two different index formulae can be used depending on the unit of item H-arm : length (mor in) or %MAC.

Index = Weigth *( HarmItem-H25)/C + K = Weigth*(%Mac - 25)*C' +K

With C' = Length of RC/(100*C)So,

Index = Weigth*(%Mac - 25)*Length of RC/(100*C) + K

%Mac = 100*C*(I-K)/Weigth*Length of RC + 25In my first message I have given some information, here new value:

for A320

Chord :4,1935

ZFI on loadsheet: 27,6

ZFW on loadsheet: 47930

K :50

C :1000

Harm :17,8015

H25 :18,85

Mac by my equation : 13,85

Mac give by loadsheet : 28,3For A330

Chord :7,27

ZFI on loadsheet :112,8

ZFWon loadsheet :158263

K :100

C :2500

Harm :31,34

H25 :33,16

Mac by my equation : 27,81

Mac give by loadsheet : 27,8

As you can see it for A330 my equation give a good result but for A320 give a wrong result, have you an explanation

I hope my new message in more comprehensible

Best regards

Note : two different index formulae can be used depending on the unit of item H-arm : length (mor in) or %MAC.

Index = Weigth *( HarmItem-H25)/C + K = Weigth*(%Mac - 25)*C' +K

With C' = Length of RC/(100*C)So,

Index = Weigth*(%Mac - 25)*Length of RC/(100*C) + K

%Mac = 100*C*(I-K)/Weigth*Length of RC + 25In my first message I have given some information, here new value:

for A320

Chord :4,1935

ZFI on loadsheet: 27,6

ZFW on loadsheet: 47930

K :50

C :1000

Harm :17,8015

H25 :18,85

Mac by my equation : 13,85

Mac give by loadsheet : 28,3For A330

Chord :7,27

ZFI on loadsheet :112,8

ZFWon loadsheet :158263

K :100

C :2500

Harm :31,34

H25 :33,16

Mac by my equation : 27,81

Mac give by loadsheet : 27,8

As you can see it for A330 my equation give a good result but for A320 give a wrong result, have you an explanation

I hope my new message in more comprehensible

Best regards

QAYS

1st Mar 2009, 13:59

hello, after hard work, I think found a good equation, I put it on paper and I submit to you

QAYS

1st Mar 2009, 16:56

I was wrong,:sad: my equation don't give a good result, worst when I submit the same data to another software which give %mac the result is not like in the loadsheet, I am lost!!!:ugh:

If you have an idea:{

Here some equations :

( Harm - H25% ) * W

Index = ----------------------- + K

C

100*C*(Index - K) 100* ( Harm - H25% )

% Mac = ------------------------------- + --------------------------

Weigth * Length of Chord Length of Chordbest regards

If you have an idea:{

Here some equations :

( Harm - H25% ) * W

Index = ----------------------- + K

C

100*C*(Index - K) 100* ( Harm - H25% )

% Mac = ------------------------------- + --------------------------

Weigth * Length of Chord Length of Chordbest regards

john_tullamarine

2nd Mar 2009, 05:51

(a) I located the Airbus document via a Google search - it looks to be a quite useful pilot reference and one that Airbus pilots within the PPRuNe fraternity should review. Indeed, much of the general information would be of use to all the heavy iron pilot folk here. It is available on a number of sites - for instance, here (http://www.britflight.com/wingfiles/performance/weightandbalance.pdf).

(b) in respect of the weight and balance engineering section, the explanation is a bit convoluted and unnecessarily difficult to follow (and I'm a weights engineer, among other things) so I have some empathy with your confusion. However, the subject is very straightforward so I shall add some comments in this post .. as I work my way through the Airbus document .. to assist your understanding.

(c) p119. The standard Airbus trimsheet is a fairly stock standard sort of document. Points to notice are

(i) the %MAC grid line which is vertical tells you what the trim datum is - in this case, 25% MAC. (At the datum, the moment calculation is M = W * 0 = 0 (zero) for all weight values so you end up with a vertical line).

(ii) the general formula for such a trimsheet is

IU = [(CG - trim datum) * weight/constant A] + constant B

where

> CG is the horizontal distance ("arm" as the pilot fraternity likes to say) of a load from the OEM FS (fuselage station) datum to wherever the load is located.

> the trim datum is a location chosen to give an accurate trimsheet. In general, the trim datum should be somewhere within the CG envelope. Airbus has chosen 25% MAC (and that's fine - but 35% MAC for the A380 and that's fine, too) .. for other aircraft the designer would pick what he/she thinks will do the job best. So, for example, most light aircraft are best suited to a trim datum somewhere near the aftmost CG envelope limit. Be aware that, should you encounter a trim sheet for an Airbus designed other than by Airbus .. it might be quite different to the Airbus document. That is, just because Airbus design the document one way, doesn't mean that that is the only way it can be done.

> (CG - trim datum) is a calculation to change arms from being measured from the FS datum to being measured from the trim datum .. it just moves the tape measure along the side view of the aeroplane .. no more, no less. Using this analogy, the end of the tape measure is moved from the OEM FS datum to the trim datum. The significance is that ALL measurements MUST be made from ONE datum .. you MUST NOT mix and match measurements lest you end up with nonsense results in your calculations.

> weight is the weight (mass, strictly) of the load under consideration

> constant A is the typical moment to IU constant intended to make the numbers a bit more workable for us mere mortals. Typically, the constant A will be a nice round number like a thousand, a hundred thousand, or suchlike. If it is not a nice round number, that indicates that there are some conversion factors, etc., embedded within it or that a scaling factor was needed for some design reason.

> constant B. If we left constant B out of it, then the IU entry line for the trim sheet would have its zero at 25% MAC in the case of the Airbus document with minus numbers (IU values) to the left and positive IU to the right. That's a bit untidy so, if we put constant B to be a useful number, we can get rid of the minus IU values. Airbus, by observation, has chosen to put constant B = 100 in the trim sheet at p119.

.. and that's about all the hard stuff involved with a trim sheet so far as pilots are concerned ..

(d) p122-124. All that this says (in a round about sort of way) is that you do the calculations just like you did in your PPL weight and balance training ..

For calculating CG .. the usual table of weights, arms, and moments. Calculated final CGs (for ZFW and TOW) come from total moment/total weight.

Keep in mind, Airbus

> is now measuring their arms from 25% MAC (H25) rather than FS 0.0.

> approach here is to start with the empty aircraft and add non-fuel and fuel items as separate, aggregrated lumps .. still basically the same as the PPL table calculation.

IU = moment/constant. One word of warning .. the Airbus document makes reference to K (what I called constant B) in (a). This constant is ONLY used for working out the trim sheet entry IU value. For IU calculations at a particular trim line, the calculation is IU change (or "delta" as we often say) and the K is left out. This is not made clear in the Airbus notes. Their (b) relates to the delta calculation .. Δ is the Greek alphabet symbol for (upper case) delta .. δ is the lower case symbol, which is more likely to be encountered.

Another point to emphasise .. you can add (subtract) weights and moments (or IU) but NOT CG values. CG values are calculated from moments (IUs) and weights.

We'll come back to the MAC formula later on ... a great example of taking something which is very simple .. and making it very complicated.

(e) p127 These ΔIndex values per kg are presented in the AHM560, nevertheless on the manual balance chart it is not possible to take into account the ΔIndex of each individual row. The trim sheet is based on loading zones. For each seat row to be accounted separately, the sheet would require a separate trim line. Commonsense prevails and a sensible zone arrangement is found. This introduces errors which need to be addressed in the design error analysis .. correction for the error usually is by compressing the apparent CG envelope limits to account for the error magnitude.

(f) the equation initially queried was from p124 of the Airbus document -

for the FS calculation -

IU = W * (H - H25)/C + K

is the standard IU equation (albeit with a few subscripts to confuse the unwary).

with the %MAC equivalent being

IU = W * (%MAC - 25) * C' + K [where C' = length of RC/(100 * C)

Keeping in mind that RC is just another name for MAC in the Airbus document, the simplest way to show that the two equations are the same is to compare them and see what results.

For the FS version the arm (measured from the trim datum) is H - H25. This can be recast into a form using %MAC (which is just a different way to look at an arm). Keep in mind that the reference to "25" is to 25% which is 25/100 and which we might signify by H25 as an arm.

Let's start with the %MAC form and work back to the FS form -

= W * [(%MAC -25) * C'] + K

= W * [(%MAC - 25) *MAC / (100 * C)] + K

= W * [%MAC * MAC / (100 * C) - 25 * MAC / (100 * C)] + K

= W * [(H - LE) * 100 * MAC / (MAC * 100 * C) - (H25 - LE) * 100 * MAC / (MAC * 100 * C)] + K

= W * [(H - LE) / C - (H25 - LE) / C] + K

= W [(H - LE) / C] - W [(H25 - LE) / C] + K

= W H / C - W LE / C - W H25 / C + W LE / C +K

= W H / C - W H2 / C + K

= W * (H - H25) / C + K

which is the FS form so it all works out fine.

(g) Looking at QAYS' examples, we need to know just which trim sheets he is comparing his calculated examples with in post #3 ?

(b) in respect of the weight and balance engineering section, the explanation is a bit convoluted and unnecessarily difficult to follow (and I'm a weights engineer, among other things) so I have some empathy with your confusion. However, the subject is very straightforward so I shall add some comments in this post .. as I work my way through the Airbus document .. to assist your understanding.

(c) p119. The standard Airbus trimsheet is a fairly stock standard sort of document. Points to notice are

(i) the %MAC grid line which is vertical tells you what the trim datum is - in this case, 25% MAC. (At the datum, the moment calculation is M = W * 0 = 0 (zero) for all weight values so you end up with a vertical line).

(ii) the general formula for such a trimsheet is

IU = [(CG - trim datum) * weight/constant A] + constant B

where

> CG is the horizontal distance ("arm" as the pilot fraternity likes to say) of a load from the OEM FS (fuselage station) datum to wherever the load is located.

> the trim datum is a location chosen to give an accurate trimsheet. In general, the trim datum should be somewhere within the CG envelope. Airbus has chosen 25% MAC (and that's fine - but 35% MAC for the A380 and that's fine, too) .. for other aircraft the designer would pick what he/she thinks will do the job best. So, for example, most light aircraft are best suited to a trim datum somewhere near the aftmost CG envelope limit. Be aware that, should you encounter a trim sheet for an Airbus designed other than by Airbus .. it might be quite different to the Airbus document. That is, just because Airbus design the document one way, doesn't mean that that is the only way it can be done.

> (CG - trim datum) is a calculation to change arms from being measured from the FS datum to being measured from the trim datum .. it just moves the tape measure along the side view of the aeroplane .. no more, no less. Using this analogy, the end of the tape measure is moved from the OEM FS datum to the trim datum. The significance is that ALL measurements MUST be made from ONE datum .. you MUST NOT mix and match measurements lest you end up with nonsense results in your calculations.

> weight is the weight (mass, strictly) of the load under consideration

> constant A is the typical moment to IU constant intended to make the numbers a bit more workable for us mere mortals. Typically, the constant A will be a nice round number like a thousand, a hundred thousand, or suchlike. If it is not a nice round number, that indicates that there are some conversion factors, etc., embedded within it or that a scaling factor was needed for some design reason.

> constant B. If we left constant B out of it, then the IU entry line for the trim sheet would have its zero at 25% MAC in the case of the Airbus document with minus numbers (IU values) to the left and positive IU to the right. That's a bit untidy so, if we put constant B to be a useful number, we can get rid of the minus IU values. Airbus, by observation, has chosen to put constant B = 100 in the trim sheet at p119.

.. and that's about all the hard stuff involved with a trim sheet so far as pilots are concerned ..

(d) p122-124. All that this says (in a round about sort of way) is that you do the calculations just like you did in your PPL weight and balance training ..

For calculating CG .. the usual table of weights, arms, and moments. Calculated final CGs (for ZFW and TOW) come from total moment/total weight.

Keep in mind, Airbus

> is now measuring their arms from 25% MAC (H25) rather than FS 0.0.

> approach here is to start with the empty aircraft and add non-fuel and fuel items as separate, aggregrated lumps .. still basically the same as the PPL table calculation.

IU = moment/constant. One word of warning .. the Airbus document makes reference to K (what I called constant B) in (a). This constant is ONLY used for working out the trim sheet entry IU value. For IU calculations at a particular trim line, the calculation is IU change (or "delta" as we often say) and the K is left out. This is not made clear in the Airbus notes. Their (b) relates to the delta calculation .. Δ is the Greek alphabet symbol for (upper case) delta .. δ is the lower case symbol, which is more likely to be encountered.

Another point to emphasise .. you can add (subtract) weights and moments (or IU) but NOT CG values. CG values are calculated from moments (IUs) and weights.

We'll come back to the MAC formula later on ... a great example of taking something which is very simple .. and making it very complicated.

(e) p127 These ΔIndex values per kg are presented in the AHM560, nevertheless on the manual balance chart it is not possible to take into account the ΔIndex of each individual row. The trim sheet is based on loading zones. For each seat row to be accounted separately, the sheet would require a separate trim line. Commonsense prevails and a sensible zone arrangement is found. This introduces errors which need to be addressed in the design error analysis .. correction for the error usually is by compressing the apparent CG envelope limits to account for the error magnitude.

(f) the equation initially queried was from p124 of the Airbus document -

for the FS calculation -

IU = W * (H - H25)/C + K

is the standard IU equation (albeit with a few subscripts to confuse the unwary).

with the %MAC equivalent being

IU = W * (%MAC - 25) * C' + K [where C' = length of RC/(100 * C)

Keeping in mind that RC is just another name for MAC in the Airbus document, the simplest way to show that the two equations are the same is to compare them and see what results.

For the FS version the arm (measured from the trim datum) is H - H25. This can be recast into a form using %MAC (which is just a different way to look at an arm). Keep in mind that the reference to "25" is to 25% which is 25/100 and which we might signify by H25 as an arm.

Let's start with the %MAC form and work back to the FS form -

= W * [(%MAC -25) * C'] + K

= W * [(%MAC - 25) *MAC / (100 * C)] + K

= W * [%MAC * MAC / (100 * C) - 25 * MAC / (100 * C)] + K

= W * [(H - LE) * 100 * MAC / (MAC * 100 * C) - (H25 - LE) * 100 * MAC / (MAC * 100 * C)] + K

= W * [(H - LE) / C - (H25 - LE) / C] + K

= W [(H - LE) / C] - W [(H25 - LE) / C] + K

= W H / C - W LE / C - W H25 / C + W LE / C +K

= W H / C - W H2 / C + K

= W * (H - H25) / C + K

which is the FS form so it all works out fine.

(g) Looking at QAYS' examples, we need to know just which trim sheets he is comparing his calculated examples with in post #3 ?

QAYS

2nd Mar 2009, 11:45

Hello, I would like thank you for your help.

I' am working on this equation, I think I could compute Harm with DOW an DOI.in fact I noticed, for the same AirCraft A320 I can have DOI totaly different:

Exemple from LoadSheet :

A320 register XXXX

DOW 43780

DOI 45,5A320 register YYYY

DOW 44128

DOI 27,1index equation

DOW= 44218

DOI=27,1

Index = W*(Harm-H25)/C + K

With

H25 = 18,850 for A320

K= 50 for A320

C= 100 for A320

Harm = ((I - K)*C)/W + H25

Harm for register YYYY= 18,33 m

Harm for register YYYY= 18,74 m

in fact I suppose each company compute Harm of each aircraft, for me, it's the only reason which explain data difference between two A320

I continue the research

I' am working on this equation, I think I could compute Harm with DOW an DOI.in fact I noticed, for the same AirCraft A320 I can have DOI totaly different:

Exemple from LoadSheet :

A320 register XXXX

DOW 43780

DOI 45,5A320 register YYYY

DOW 44128

DOI 27,1index equation

DOW= 44218

DOI=27,1

Index = W*(Harm-H25)/C + K

With

H25 = 18,850 for A320

K= 50 for A320

C= 100 for A320

Harm = ((I - K)*C)/W + H25

Harm for register YYYY= 18,33 m

Harm for register YYYY= 18,74 m

in fact I suppose each company compute Harm of each aircraft, for me, it's the only reason which explain data difference between two A320

I continue the research

john_tullamarine

2nd Mar 2009, 22:30

I think I could compute Harm with DOW an DOI

Of course you can -

IU = W(H-H25)/C +K

can be rearranged to give

H = C(IU-K)/W + H25

I noticed, for the same AirCraft A320 I can have DOI totaly different

Not at all unusual. This just reflects a range of empty weights and CGs across a similar fleet (presuming similar configuration and the same IU formula, of course). For the example you cite, CGs of 18.33m and 18.74m possibly are a little too far apart for comfort and need investigation.

It is important to realise that each aircraft is an individual machine and will have small differences from its apparently identical fleet colleagues.

Some operators use fleet average data for empty weight and IU. If this is your case, then part of the confusion may relate to having apparently identical data in the fleet average declared data .. it is important to keep in mind that the average comes from a small range of data which is used to calculate the average..

However, getting back to your original concerns, can you indicate the specific trimsheets from which you obtained your MAC values ? If the trimsheet is consistent with the Airbus calculation models then the reason for the apparent MAC difference should stand out.

Of course you can -

IU = W(H-H25)/C +K

can be rearranged to give

H = C(IU-K)/W + H25

I noticed, for the same AirCraft A320 I can have DOI totaly different

Not at all unusual. This just reflects a range of empty weights and CGs across a similar fleet (presuming similar configuration and the same IU formula, of course). For the example you cite, CGs of 18.33m and 18.74m possibly are a little too far apart for comfort and need investigation.

It is important to realise that each aircraft is an individual machine and will have small differences from its apparently identical fleet colleagues.

Some operators use fleet average data for empty weight and IU. If this is your case, then part of the confusion may relate to having apparently identical data in the fleet average declared data .. it is important to keep in mind that the average comes from a small range of data which is used to calculate the average..

However, getting back to your original concerns, can you indicate the specific trimsheets from which you obtained your MAC values ? If the trimsheet is consistent with the Airbus calculation models then the reason for the apparent MAC difference should stand out.

QAYS

3rd Mar 2009, 10:50

However, getting back to your original concerns, can you indicate the specific trimsheets from which you obtained your MAC values ? If the trimsheet is consistent with the Airbus calculation models then the reason for the apparent MAC difference should stand out.In fact I obtain data (DOW and DOI) from Loadsheet gaetan , I Took It when I worked In Orly airport like Fligth dispacther.

So I prepared Two Fligth, one which have DOW = 44128 with DOI =27,1

and an other DOW =4378 and DOI=45,5

I noticed when I take paper trim sheet A320 from company alpha I can't use it for all A320, in fact for the first plane (DOI 27,1) le LITOW is out.

So I deduct each company have his owner trim sheet, but there must be an generic equation which give %Mac for all Airbus or aircraft.

I have a doubt about this equation % Mac =100*C*(I-K)/Weigth*Length of RC + 25 and I have a doubt about 25, I think this value is result of this equation :

100*(Harm -hH25)/Lenght of Chord

PS: I ma sorry if I repeat myself, but I'm very perplexed about determination % MAC,

I Continue the research

thank you

So I prepared Two Fligth, one which have DOW = 44128 with DOI =27,1

and an other DOW =4378 and DOI=45,5

I noticed when I take paper trim sheet A320 from company alpha I can't use it for all A320, in fact for the first plane (DOI 27,1) le LITOW is out.

So I deduct each company have his owner trim sheet, but there must be an generic equation which give %Mac for all Airbus or aircraft.

I have a doubt about this equation % Mac =100*C*(I-K)/Weigth*Length of RC + 25 and I have a doubt about 25, I think this value is result of this equation :

100*(Harm -hH25)/Lenght of Chord

PS: I ma sorry if I repeat myself, but I'm very perplexed about determination % MAC,

I Continue the research

thank you

john_tullamarine

3rd Mar 2009, 11:44

I obtain data (DOW and DOI) from Loadsheet gaetan

Question is whether the different loadsheets have the same design equation for IU. Keep in mind that the IU equation can vary from trimsheet to trimsheet .. ie I could design 10 A320 trimsheets which might look generally similar but have incompatible IU equations. So far as the pilot is concerned, the only obvious difference would be the IU value to start the trimsheet calculation.

Hence the need for us to know just which trimsheets you are using .. you may end up needing to post a scan of them so that we can reverse engineer the IU equation to check out just why you are getting apparently incompatible answers.

when I take paper trim sheet A320 from company alpha I can't use it for all A320, in fact for the first plane (DOI 27,1) le LITOW is out.

Exactly .. you MUST NOT use a trimsheet for another operator unless you have established that the document is compatible both for configuration and IU equation.

there must be an generic equation which give %Mac for all Airbus or aircraft.

No, not at all when it comes to trimsheets as you are plotting %MAC as a set of values of W by IU so, if the IU equation is different, then you need to take that into account when comparing things ... you MUST compare apples with apples for the numbers to make much sense.

The relationships are OK for basic calculations such as we have been using above. However, the IU equation is variable according to the views of the trimsheet designer ... so two different sheets may .. or may not ... be compatible when it comes to playing with the numbers.

It would be reasonable to presume that any trimsheet designed by Airbus will be as they describe in their document. Indeed, I would imagine that most airline Airbus operators would follow the Airbus model for convenience.

However, if I, or some other designer, were to design an Airbus trimsheet that trimsheet might be quite different in the detail when compared to the Airbus trimsheet. As I suggested earlier, just because Airbus chooses to design a trimsheet one way doesn't mean that that is the only way. Same thing applies with Boeing or any other OEM.

I have a doubt about this equation % Mac =100*C*(I-K)/Weigth*Length of RC + 25 and I have a doubt about 25,

You appear to have left out some brackets above. Just to clarify, the Airbus equation from p124 becomes -

%MAC = 25 + 100*C*(I-K)/(W*MAC)

(I've rearranged it a bit to emphasis what the brackets are doing .. RC is the same as MAC)

Nothing wrong with the Airbus equation. What do you see as the difficulty and we can discuss it to remove the concern ?

The "25" simply relates to the Airbus choice of trim datum to be 25%MAC and is 25%.

I'm sure that a few more exchanges and we will have your concerns put to rest.

Looking forward to your reply.

Question is whether the different loadsheets have the same design equation for IU. Keep in mind that the IU equation can vary from trimsheet to trimsheet .. ie I could design 10 A320 trimsheets which might look generally similar but have incompatible IU equations. So far as the pilot is concerned, the only obvious difference would be the IU value to start the trimsheet calculation.

Hence the need for us to know just which trimsheets you are using .. you may end up needing to post a scan of them so that we can reverse engineer the IU equation to check out just why you are getting apparently incompatible answers.

when I take paper trim sheet A320 from company alpha I can't use it for all A320, in fact for the first plane (DOI 27,1) le LITOW is out.

Exactly .. you MUST NOT use a trimsheet for another operator unless you have established that the document is compatible both for configuration and IU equation.

there must be an generic equation which give %Mac for all Airbus or aircraft.

No, not at all when it comes to trimsheets as you are plotting %MAC as a set of values of W by IU so, if the IU equation is different, then you need to take that into account when comparing things ... you MUST compare apples with apples for the numbers to make much sense.

The relationships are OK for basic calculations such as we have been using above. However, the IU equation is variable according to the views of the trimsheet designer ... so two different sheets may .. or may not ... be compatible when it comes to playing with the numbers.

It would be reasonable to presume that any trimsheet designed by Airbus will be as they describe in their document. Indeed, I would imagine that most airline Airbus operators would follow the Airbus model for convenience.

However, if I, or some other designer, were to design an Airbus trimsheet that trimsheet might be quite different in the detail when compared to the Airbus trimsheet. As I suggested earlier, just because Airbus chooses to design a trimsheet one way doesn't mean that that is the only way. Same thing applies with Boeing or any other OEM.

I have a doubt about this equation % Mac =100*C*(I-K)/Weigth*Length of RC + 25 and I have a doubt about 25,

You appear to have left out some brackets above. Just to clarify, the Airbus equation from p124 becomes -

%MAC = 25 + 100*C*(I-K)/(W*MAC)

(I've rearranged it a bit to emphasis what the brackets are doing .. RC is the same as MAC)

Nothing wrong with the Airbus equation. What do you see as the difficulty and we can discuss it to remove the concern ?

The "25" simply relates to the Airbus choice of trim datum to be 25%MAC and is 25%.

I'm sure that a few more exchanges and we will have your concerns put to rest.

Looking forward to your reply.

QAYS

3rd Mar 2009, 12:26

Nothing wrong with the Airbus equation. What do you see as the difficulty and we can discuss it to remove the concern ?I don't want to say Airbus equation is wrong, but i don't understand it.:ugh:

I don't understand why, the same equation is able to compute %Mac correctly for one aircraft and isn't able to compute this %mac for an other.

The best way would be to meet pilot.

To explain the reason about my research, I created software which is able to compute the aircraft loading , like gaetan software.

I found Harm about Hold (in airbus doc) and to determine Index about Cabin I use trim sheet about aircraft, the first results is very good, My Index ZFW,TOW,and LDW are equal with values which are compute by gaetan (airfrance software), The only equation I don't have is equation %Mac,

So i search on Web, generic equation or not,which is able to compute %Mac for any aircraft, when I am able to compute Index value of ZFW,TOW,and LDW

thank you much for your understanding and for your help

I don't understand why, the same equation is able to compute %Mac correctly for one aircraft and isn't able to compute this %mac for an other.

The best way would be to meet pilot.

To explain the reason about my research, I created software which is able to compute the aircraft loading , like gaetan software.

I found Harm about Hold (in airbus doc) and to determine Index about Cabin I use trim sheet about aircraft, the first results is very good, My Index ZFW,TOW,and LDW are equal with values which are compute by gaetan (airfrance software), The only equation I don't have is equation %Mac,

So i search on Web, generic equation or not,which is able to compute %Mac for any aircraft, when I am able to compute Index value of ZFW,TOW,and LDW

thank you much for your understanding and for your help

john_tullamarine

3rd Mar 2009, 22:04

but i don't understand it

I had to get out pencil and paper to work it through as well, so don't feel bad at all. The Airbus explanations are a bit (and unnecessarily) convoluted in my view .. but, nonetheless, correct. The aim, now, is to work out just where you are having problems and then fix those problems. Keep firmly in mind that this stuff is pretty straightforward but it requires meticulous housekeeping to avoid error.

the same equation is able to compute %Mac correctly for one aircraft and isn't able to compute this %mac for an other.

If the equation is correct, then there must be something different about the aircraft. That is what we need to find out.

The best way would be to meet pilot.

I suggest not .. the average pilot has a practical competence with the completion of trimsheets .. but generally a limited understanding of their design and construction.

The only equation I don't have is equation %Mac,

You will have to show us what data you are using .. ie trimsheet, software output, etc. Otherwise we cannot determine where the error occurs. My guess is that you either have

(a) an incorrect implementation of the equation, or

(b) different and incompatible trimsheet designs.

Until we can see and test we probably can't go much further.

If you don't want to post such documents by all means email a scan direct to me and I can sanitise the original for an explanatory post.

So i search on Web, generic equation or not,which is able to compute %Mac for any aircraft,

This is possibly a cause for your problem. The %MAC equations discussed in previous posts work just fine but only for the correct and applicable datum position. Because the IU equation for trimsheets can vary according to the preference of the trimsheet designer one requires a fairly complex equation to cover all the possibilities and then there remains the problem of reverse engineering an individual trimsheet to find equation constants.

I had to get out pencil and paper to work it through as well, so don't feel bad at all. The Airbus explanations are a bit (and unnecessarily) convoluted in my view .. but, nonetheless, correct. The aim, now, is to work out just where you are having problems and then fix those problems. Keep firmly in mind that this stuff is pretty straightforward but it requires meticulous housekeeping to avoid error.

the same equation is able to compute %Mac correctly for one aircraft and isn't able to compute this %mac for an other.

If the equation is correct, then there must be something different about the aircraft. That is what we need to find out.

The best way would be to meet pilot.

I suggest not .. the average pilot has a practical competence with the completion of trimsheets .. but generally a limited understanding of their design and construction.

The only equation I don't have is equation %Mac,

You will have to show us what data you are using .. ie trimsheet, software output, etc. Otherwise we cannot determine where the error occurs. My guess is that you either have

(a) an incorrect implementation of the equation, or

(b) different and incompatible trimsheet designs.

Until we can see and test we probably can't go much further.

If you don't want to post such documents by all means email a scan direct to me and I can sanitise the original for an explanatory post.

So i search on Web, generic equation or not,which is able to compute %Mac for any aircraft,

This is possibly a cause for your problem. The %MAC equations discussed in previous posts work just fine but only for the correct and applicable datum position. Because the IU equation for trimsheets can vary according to the preference of the trimsheet designer one requires a fairly complex equation to cover all the possibilities and then there remains the problem of reverse engineering an individual trimsheet to find equation constants.

QAYS

4th Mar 2009, 13:41

Hello, Goooooooooal (I think)

I found equation on AHM 560 of airlingus, in fact In this doc I found equation to compute Index and % Mac, I have explaination about almost constant.

as I thought it, each company for his each aircraft give LEMAC

Index =W*(Sta - Ref.Sta)/C + K

% MAC =( 100*C.(I-K) )/(MAC*W) + 100*(Ref.Sta - LEMAC)/(MAC)

W = Weight, actual

Sta. = Station, horizontal distance from station zero to the location

Ref.Sta. = Reference Station/axis. Selected station for calculation purpose

K = Constant used as a plus value to avoid negative index figures

C = Constant used as a denominator to convert moment values into

index values

I = Index value corresponding to respective weight

MAC = Length of Mean Aerodynamic Chord

LEMAC = Horizontal distance from the station zero to location of the

Leading Edge of the MAC

Now I nead found LEMAC for each aircraft which use in my software, because it's the only variable which move from aircraft to an onther aircraft

I made some test, and i ma on good way

PS: As i tell you in my previous posts, my english is poor and sometimes I don't understand all what you write, but I try to translate et I want thank you for all your help

See you later

Best regards

I found equation on AHM 560 of airlingus, in fact In this doc I found equation to compute Index and % Mac, I have explaination about almost constant.

as I thought it, each company for his each aircraft give LEMAC

Index =W*(Sta - Ref.Sta)/C + K

% MAC =( 100*C.(I-K) )/(MAC*W) + 100*(Ref.Sta - LEMAC)/(MAC)

W = Weight, actual

Sta. = Station, horizontal distance from station zero to the location

Ref.Sta. = Reference Station/axis. Selected station for calculation purpose

K = Constant used as a plus value to avoid negative index figures

C = Constant used as a denominator to convert moment values into

index values

I = Index value corresponding to respective weight

MAC = Length of Mean Aerodynamic Chord

LEMAC = Horizontal distance from the station zero to location of the

Leading Edge of the MAC

Now I nead found LEMAC for each aircraft which use in my software, because it's the only variable which move from aircraft to an onther aircraft

I made some test, and i ma on good way

PS: As i tell you in my previous posts, my english is poor and sometimes I don't understand all what you write, but I try to translate et I want thank you for all your help

See you later

Best regards

john_tullamarine

5th Mar 2009, 03:36

Index =W*(Sta - Ref.Sta)/C + K

Stock standard IU equation for a trimsheet as we have discussed before.

% MAC =( 100*C.(I-K) )/(MAC*W) + 100*(Ref.Sta - LEMAC)/(MAC)

This equation follows by some manipulation .... but it's a lot easier just to read the %MAC off the envelope overlay grid ie enter IU and W and read off %MAC. This %MAC equation is quite unnecessary and not even used for plotting the grid in the design phase of the trimsheet (although it certainly could be). As you will always work through a fuselage station for CG, it is a lot easier just to use the general basic equation -

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

What concerns me is that you are making something very simple into something a lot more complex ... but for no advantage to you.

as I thought it, each company for his each aircraft give LEMAC

I may be misunderstanding your intent here. The LEMAC is provided by the aircraft OEM (in the WBM, AFM, TCDS, etc). Not determined by the operator.

my english is poor and sometimes I don't understand all what you write

that's my fault .. not yours.

Stock standard IU equation for a trimsheet as we have discussed before.

% MAC =( 100*C.(I-K) )/(MAC*W) + 100*(Ref.Sta - LEMAC)/(MAC)

This equation follows by some manipulation .... but it's a lot easier just to read the %MAC off the envelope overlay grid ie enter IU and W and read off %MAC. This %MAC equation is quite unnecessary and not even used for plotting the grid in the design phase of the trimsheet (although it certainly could be). As you will always work through a fuselage station for CG, it is a lot easier just to use the general basic equation -

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

What concerns me is that you are making something very simple into something a lot more complex ... but for no advantage to you.

as I thought it, each company for his each aircraft give LEMAC

I may be misunderstanding your intent here. The LEMAC is provided by the aircraft OEM (in the WBM, AFM, TCDS, etc). Not determined by the operator.

my english is poor and sometimes I don't understand all what you write

that's my fault .. not yours.

QAYS

5th Mar 2009, 18:19

I have impression I have diffilculties to make me understand.:{

In fact with this equation :

% MAC =( 100*C.(I-K) )/(MAC*W) + 100*(Ref.Sta - LEMAC)/(MAC)

C = 1000 for A320 / given by airbus nevertheless, for Airlingus C= 500 :confused:

K = 50 for A320 / given by airbus

MAC = 4,1935m for A320 / given by airbus

Ref.Sta = 18,850m for A320 / given by airbus

I = Compute by loadsheet

W = Compute by loading Cabin and Hold

So I deduct the only data which is able to explain difference between two register is LEMAC, no :confused:

==>% MAC =( 100*C.(I-K) )/(MAC*W) + 100*(Ref.Sta - LEMAC)/(MAC)

==>LEMAC = %MAC*MAC/100 + C.(I-K) )/(W) + Ref.Sta

If I take my two A320

AirCraft 1 :

% MAC = 28,3%

IZW = 27,6

ZFW = 47930

Lemac = 19,5

AirCraft 1 :

MAC = 32

IZW = 49,6

ZFW = 54621

Lemac = 20,19

Perhaps I mix data which would not have like %MAC and other data !! :ooh:

But I Don't desperate,:= I will find this equation

In fact with this equation :

% MAC =( 100*C.(I-K) )/(MAC*W) + 100*(Ref.Sta - LEMAC)/(MAC)

C = 1000 for A320 / given by airbus nevertheless, for Airlingus C= 500 :confused:

K = 50 for A320 / given by airbus

MAC = 4,1935m for A320 / given by airbus

Ref.Sta = 18,850m for A320 / given by airbus

I = Compute by loadsheet

W = Compute by loading Cabin and Hold

So I deduct the only data which is able to explain difference between two register is LEMAC, no :confused:

==>% MAC =( 100*C.(I-K) )/(MAC*W) + 100*(Ref.Sta - LEMAC)/(MAC)

==>LEMAC = %MAC*MAC/100 + C.(I-K) )/(W) + Ref.Sta

If I take my two A320

AirCraft 1 :

% MAC = 28,3%

IZW = 27,6

ZFW = 47930

Lemac = 19,5

AirCraft 1 :

MAC = 32

IZW = 49,6

ZFW = 54621

Lemac = 20,19

Perhaps I mix data which would not have like %MAC and other data !! :ooh:

But I Don't desperate,:= I will find this equation

john_tullamarine

5th Mar 2009, 22:00

I have impression I have diffilculties to make me understand

Have no worry. One of the difficulties with any discussion involving folk without an idiomatic common language is making sure that what one is saying is what the other is hearing and comprehending and that applies for both people. Just means that we take a little bit longer to work through a discussion and that is fine.

nevertheless, for Airlingus C= 500

This suggests that the two trimsheets are not the same. I need to see the other trimsheet to check if that is the case or if, for instance, the 500 reference is in error.

So I deduct the only data which is able to explain difference between two register is LEMAC

LEMAC is a fixed position, defined by the OEM design. This cannot be the cause, I fear.

Your calculations are fine.

However, we don't have enough information to work out where the apparent error comes from. You will have to let me see both the trimsheets so that I can compare them. At this stage, the likely answer is that you are trying to treat two different designs as the same and that just won't work.

Can you scan both the trimsheets you are working with and email them to me ? That way there can be no confusion regarding just what data you are working with.

Have no worry. One of the difficulties with any discussion involving folk without an idiomatic common language is making sure that what one is saying is what the other is hearing and comprehending and that applies for both people. Just means that we take a little bit longer to work through a discussion and that is fine.

nevertheless, for Airlingus C= 500

This suggests that the two trimsheets are not the same. I need to see the other trimsheet to check if that is the case or if, for instance, the 500 reference is in error.

So I deduct the only data which is able to explain difference between two register is LEMAC

LEMAC is a fixed position, defined by the OEM design. This cannot be the cause, I fear.

Your calculations are fine.

However, we don't have enough information to work out where the apparent error comes from. You will have to let me see both the trimsheets so that I can compare them. At this stage, the likely answer is that you are trying to treat two different designs as the same and that just won't work.

Can you scan both the trimsheets you are working with and email them to me ? That way there can be no confusion regarding just what data you are working with.

QAYS

7th Mar 2009, 10:02

Hello, I' m very sorry , I haven't got scan to send you trim sheet.

I Will try to explain it.

When I compute UI for Hold 1 with Airbus data:

Hold1 Harm = 12.283 m from Airbus Doc

Unit Index = W*(Sta - Ref.Sta)/C This equation compute Index for An item

With

Sta = Harm= 12,283 from Airbus Doc

Ref.Sta = 18,850 from Airbus Doc

C=1000 from Airbus Doc

So Unit Index = 0,0064 for Hold 1The first come from AirFrance A320-100

Hold 1 ==>1000 kg = ~6,4UI i can deduct For Hold1 0,0064 UI/Kg :ok:

there are the same calc for all HoldThe second (Trim sheet) come from NouvelAir

Hold 1 ==>500 kg = ~3,2UI i can deduct For Hold1 0,0064 UI/Kg :ok:The third (Trim sheet) come from XL AirWay

Hold 1 ==> 500kg = ~1,1 UI :confused:

I will try to scan the LOADSHEET and i will send it to you

In fact I didn't use trim sheet to make my calcul, but i used electronic Loadsheet create by gaetan (airfrance software) to control my result

the Unit Index are compute from My software with airbus data or with reading trim sheet when when I have one

In fact to create one aircraft on my software, I have two opportunity:

Case 1 : I have Doc Airbus ou AHM:

- For Hold I hava Airbus Data.

- For Cabin I use Trim sheet (because earch aircraft have onwer configuration)

Case 2 : I don't have Doc or AHM

- For Cabin and Hold I use trim sheet If I have one

That's why I can treat any aircraft when I have got trimsheet, I study It and I save all informations in my soft

according to you, I found Aircraft manual about Boeing with Arm of Hold, can I use the same equation to compute Unit Index?

best regards

I Will try to explain it.

When I compute UI for Hold 1 with Airbus data:

Hold1 Harm = 12.283 m from Airbus Doc

Unit Index = W*(Sta - Ref.Sta)/C This equation compute Index for An item

With

Sta = Harm= 12,283 from Airbus Doc

Ref.Sta = 18,850 from Airbus Doc

C=1000 from Airbus Doc

So Unit Index = 0,0064 for Hold 1The first come from AirFrance A320-100

Hold 1 ==>1000 kg = ~6,4UI i can deduct For Hold1 0,0064 UI/Kg :ok:

there are the same calc for all HoldThe second (Trim sheet) come from NouvelAir

Hold 1 ==>500 kg = ~3,2UI i can deduct For Hold1 0,0064 UI/Kg :ok:The third (Trim sheet) come from XL AirWay

Hold 1 ==> 500kg = ~1,1 UI :confused:

I will try to scan the LOADSHEET and i will send it to you

In fact I didn't use trim sheet to make my calcul, but i used electronic Loadsheet create by gaetan (airfrance software) to control my result

the Unit Index are compute from My software with airbus data or with reading trim sheet when when I have one

In fact to create one aircraft on my software, I have two opportunity:

Case 1 : I have Doc Airbus ou AHM:

- For Hold I hava Airbus Data.

- For Cabin I use Trim sheet (because earch aircraft have onwer configuration)

Case 2 : I don't have Doc or AHM

- For Cabin and Hold I use trim sheet If I have one

That's why I can treat any aircraft when I have got trimsheet, I study It and I save all informations in my soft

according to you, I found Aircraft manual about Boeing with Arm of Hold, can I use the same equation to compute Unit Index?

best regards

john_tullamarine

10th Mar 2009, 00:45

I haven't got scan to send you trim sheet.

Oh, well, never mind ... let's work out a Plan B.

When I compute UI for Hold 1 with Airbus data: Hold1 Harm = 12.283 m from Airbus Doc

As the station is forward of the datum (Ref Stn), the ΔIU has to be negative. For interest, my calculation gives

ΔIU = -0.006567 / kg

The third (Trim sheet) come from XL AirWay Hold 1 ==> 500kg = ~1,1 UI

Ah, now this presents a problem. Most likely, the IU equation is different.

I will try to scan the LOADSHEET and i will send it to you

This is fairly important as, without the pictures of the various sheets, I can't figure out where the error is.

i used electronic Loadsheet create by gaetan (airfrance software) to control my result

That's fine but, if we sort out the trimsheets first, then we have somewhere to start and can look at the software.

I found Aircraft manual about Boeing with Arm of Hold, can I use the same equation to compute Unit Index?

You can only use the same IU equation if the two systems use the same equation. The problem is that there is no reason for different loading systems to use the same IU equation and, very often, the equations will be different. If is essential to make sure that sheets are compatible before you start running calculations other than using the sheet and the declared entry data.

Oh, well, never mind ... let's work out a Plan B.

When I compute UI for Hold 1 with Airbus data: Hold1 Harm = 12.283 m from Airbus Doc

As the station is forward of the datum (Ref Stn), the ΔIU has to be negative. For interest, my calculation gives

ΔIU = -0.006567 / kg

The third (Trim sheet) come from XL AirWay Hold 1 ==> 500kg = ~1,1 UI

Ah, now this presents a problem. Most likely, the IU equation is different.

I will try to scan the LOADSHEET and i will send it to you

This is fairly important as, without the pictures of the various sheets, I can't figure out where the error is.

i used electronic Loadsheet create by gaetan (airfrance software) to control my result

That's fine but, if we sort out the trimsheets first, then we have somewhere to start and can look at the software.

I found Aircraft manual about Boeing with Arm of Hold, can I use the same equation to compute Unit Index?

You can only use the same IU equation if the two systems use the same equation. The problem is that there is no reason for different loading systems to use the same IU equation and, very often, the equations will be different. If is essential to make sure that sheets are compatible before you start running calculations other than using the sheet and the declared entry data.

Charlie_Fox

11th Mar 2010, 13:04

Would you mind if I joined this discussion? I've done what QAYS is trying to do for several aircraft but only Boeing and McDonnell Douglas, never Airbus.

However the principle is the same.

You need certain basic information before you start (as has already been mentioned), most of it available in the manufacturer's manual.

LEMAC (leading edge of MAC)

Length of MAC

Reference arm

Constant (used to convert index into manageable figure)

When you have the operating empty weight and index, it becomes

relatively easy then to calculate %MAC.

%MAC = (Constant x (index/weight) + reference point-LEMAC)/length of MAC *100

Think I'm just saying the same thing in different words?

However the principle is the same.

You need certain basic information before you start (as has already been mentioned), most of it available in the manufacturer's manual.

LEMAC (leading edge of MAC)

Length of MAC

Reference arm

Constant (used to convert index into manageable figure)

When you have the operating empty weight and index, it becomes

relatively easy then to calculate %MAC.

%MAC = (Constant x (index/weight) + reference point-LEMAC)/length of MAC *100

Think I'm just saying the same thing in different words?

john_tullamarine

12th Mar 2010, 00:28

Would you mind if I joined this discussion?

The more the merrier as with all threads ..

I've done what QAYS is trying to do for several aircraft but only Boeing and McDonnell Douglas, never Airbus. However the principle is the same.

This stuff is all the same whether we are talking a glider, C172, or B747. Once you get the head around the techniques it is all a bit of a doddle. Getting the head around it in the first place is the problem.

Think I'm just saying the same thing in different words?

Absolutely ... but why make something simple so complex ? Doesn't appear to achieve anything to a simple Simon like me ...

Explanation -

If we ignore any IU shift for, say, a trimsheet, the general formula becomes

IU = [(FS-D)*WT]/C

which, on rearrangement, becomes

FS = [(IU*C)/WT] + D

and, if you plug that expression for FS into the stock standard %MAC equation

%MAC = {[(FS-LEMAC)]/MAC}*100

you end up with

%MAC = {{[(IU*C)/WT] + D - LEMAC}/MAC} * 100

where D = reference arm .. which is more generally referred to as the trim datum.

The more the merrier as with all threads ..

I've done what QAYS is trying to do for several aircraft but only Boeing and McDonnell Douglas, never Airbus. However the principle is the same.

This stuff is all the same whether we are talking a glider, C172, or B747. Once you get the head around the techniques it is all a bit of a doddle. Getting the head around it in the first place is the problem.

Think I'm just saying the same thing in different words?

Absolutely ... but why make something simple so complex ? Doesn't appear to achieve anything to a simple Simon like me ...

Explanation -

If we ignore any IU shift for, say, a trimsheet, the general formula becomes

IU = [(FS-D)*WT]/C

which, on rearrangement, becomes

FS = [(IU*C)/WT] + D

and, if you plug that expression for FS into the stock standard %MAC equation

%MAC = {[(FS-LEMAC)]/MAC}*100

you end up with

%MAC = {{[(IU*C)/WT] + D - LEMAC}/MAC} * 100

where D = reference arm .. which is more generally referred to as the trim datum.

DownIn3Green

13th Mar 2010, 04:36

LEMAC, TMAC...Basic PPL stuff guys, alluded to by John in the beginning of this thread...applies to all A/C...

Weight x Arm = Moment...

CG = Total Moment divided by total weight...

Very simple, really...

Weight x Arm = Moment...

CG = Total Moment divided by total weight...

Very simple, really...

john_tullamarine

13th Mar 2010, 12:29

Very simple, really...

True .. but only once one gets one's head around the techniques.

When playing with trimsheets one sees a range of designs ranging from very bad through to very good (and the latter, generally, are presented fairly simply).

I can recall a task to design a GII trimsheet many years ago now (about 30 years ago, as I recall). That little exercise took me some weeks to figure out a way to present a tidy double envelope to account for trimming at ZFW but still needing to determine CG at takeoff (as I recall that was the main problem). Once I figured out a way to do it, it was all very simple .. but I had a few worrying moments along the way trying to make something work. Another very experienced engineer had given up and suggested that it just couldn't be done ..

True .. but only once one gets one's head around the techniques.

When playing with trimsheets one sees a range of designs ranging from very bad through to very good (and the latter, generally, are presented fairly simply).

I can recall a task to design a GII trimsheet many years ago now (about 30 years ago, as I recall). That little exercise took me some weeks to figure out a way to present a tidy double envelope to account for trimming at ZFW but still needing to determine CG at takeoff (as I recall that was the main problem). Once I figured out a way to do it, it was all very simple .. but I had a few worrying moments along the way trying to make something work. Another very experienced engineer had given up and suggested that it just couldn't be done ..

DownIn3Green

14th Mar 2010, 00:17

John... agree with you, however, my point was, if you have the basics down, you don't need all the "newfangled" automated cr@p to work this stuff out...

For example...B-727F...12 pallet positions...find out how much each one weighs and have them loaded accordingly...too heavy?...take less fuel and make a stop or leave a pallet or two behind and go N/S...

Oops, leaving a pallet or two behind makes the remainder of the load out of limits...NO PROBLEM!!!

Rework the numbers, rearrange the pallets and go on about your business...makes life hell for the handlers I know, but in the final analysis, it is "simple, really"...Yes Really...

For example...B-727F...12 pallet positions...find out how much each one weighs and have them loaded accordingly...too heavy?...take less fuel and make a stop or leave a pallet or two behind and go N/S...

Oops, leaving a pallet or two behind makes the remainder of the load out of limits...NO PROBLEM!!!

Rework the numbers, rearrange the pallets and go on about your business...makes life hell for the handlers I know, but in the final analysis, it is "simple, really"...Yes Really...

john_tullamarine

14th Mar 2010, 12:35

B-727F

another freighter enthusiast .. pass, friend. Passengers really are a nuisance in the end analysis.

another freighter enthusiast .. pass, friend. Passengers really are a nuisance in the end analysis.

DownIn3Green

15th Mar 2010, 00:00

John, not "enthuisast", however, got stuck with it and adapted...As for my prior (to freight) 18 yrs plus of instructing/FAR135/121 Pax experience, I still feel the same, with the exception that when the load sheet is presented, you really do have to check and double check, because the agent is just trying to get you out of there...

For example....on contract to a UK hiring company, flying a S. African (SAFAIR) B-727-200 for Cameroon Airlines (filling in for their B-737-200, which was in Joburg undergoing a "C" Check with , you guessed it SAFAIR), I had to constantly examine and re-examine the loadsheet...

It was printed in French, fuel was in Kilos, and 90% of the time it was done on the numbers for the 737, not the 727 we were in...it almost bit my backside once, but never again...that's called experience...fool me once, shame on you....

Still, after all was said and done, we ended up doing our own W&B and life was great...even in Douala...Great people and wonderful hosts....First Rate, as far as that area of the world....

For example....on contract to a UK hiring company, flying a S. African (SAFAIR) B-727-200 for Cameroon Airlines (filling in for their B-737-200, which was in Joburg undergoing a "C" Check with , you guessed it SAFAIR), I had to constantly examine and re-examine the loadsheet...

It was printed in French, fuel was in Kilos, and 90% of the time it was done on the numbers for the 737, not the 727 we were in...it almost bit my backside once, but never again...that's called experience...fool me once, shame on you....

Still, after all was said and done, we ended up doing our own W&B and life was great...even in Douala...Great people and wonderful hosts....First Rate, as far as that area of the world....

john_tullamarine

15th Mar 2010, 01:24

when the load sheet is presented, you really do have to check and double check, because the agent is just trying to get you out of there...

Never a truer statement uttered.

Likewise, I have fond memories of a 737-200 training contract in RSA some years ago. Lovely people, in the main, and a most interesting country.

I guess the enthusiasm for doing things at 0-dark-30 wore off a bit for me after some years and, if I were to be completely honest, I was just a little bit glad to get back onto normal passenger operations ..

Never a truer statement uttered.

Likewise, I have fond memories of a 737-200 training contract in RSA some years ago. Lovely people, in the main, and a most interesting country.

I guess the enthusiasm for doing things at 0-dark-30 wore off a bit for me after some years and, if I were to be completely honest, I was just a little bit glad to get back onto normal passenger operations ..

Bowser99

26th Oct 2010, 14:55

hi all,

in the examples above, the C constant is always positive. Does anyone know whether the C constant is always positive or can it be negative?

in the examples above, the C constant is always positive. Does anyone know whether the C constant is always positive or can it be negative?

john_tullamarine

26th Oct 2010, 20:39

(a) if you wanted to, sure. But why bother ?

(b) main effect would be to mirror the trimsheet image for no purpose other than confusing the great majority beyond reasonable comprehension.

(b) main effect would be to mirror the trimsheet image for no purpose other than confusing the great majority beyond reasonable comprehension.

Screwballs

28th Jan 2011, 11:37

Just want to ask a basic question, when looking at the FCOM on how to do a manual load sheet it says:

DATA

Dry Operating Weight = 42500 kg and CG = 27 % (H-arm = 18.93 m)

Deviation or adjustment = + 100 kg in zone F

Cargo = 5500 kg with the following distribution :

cargo 1 = 2000 kg ; cargo 3 = 1500 kg ; cargo 4 = 1500 kg ; cargo 5 = 500 kg

Passengers = 145 pax with the following distribution :

cabin OA = 50 ; cabin OB = 55 ; cabin OC = 40

Ramp Fuel = 13200 kg ; Taxi Fuel = 200 kg ; Fuel Density = 0.785 kg/l

DESCRIPTION

Enter Master data in (1).

Compute Dry Operating Weight Index using the formula indicated in (2) and report in (3).

Dry Operating Index = 53.4.

My question is about the H-arm. I looked at the Getting to Grips document and there is no definition of H-arm. I understand the H-arm is a reference point but would it stay the same on every aircraft on an identical fleet? And if not, where would you find the specific aircraft's H-arm to enter the Airbus manual loadsheet in the top left box, page 121 in the Getting to Grips document? In this example above, is H-arm = 18.93 a generic figure or is that the one to use on the manual loadsheet?

Thanks for the replies,

Screwballs

DATA

Dry Operating Weight = 42500 kg and CG = 27 % (H-arm = 18.93 m)

Deviation or adjustment = + 100 kg in zone F

Cargo = 5500 kg with the following distribution :

cargo 1 = 2000 kg ; cargo 3 = 1500 kg ; cargo 4 = 1500 kg ; cargo 5 = 500 kg

Passengers = 145 pax with the following distribution :

cabin OA = 50 ; cabin OB = 55 ; cabin OC = 40

Ramp Fuel = 13200 kg ; Taxi Fuel = 200 kg ; Fuel Density = 0.785 kg/l

DESCRIPTION

Enter Master data in (1).

Compute Dry Operating Weight Index using the formula indicated in (2) and report in (3).

Dry Operating Index = 53.4.

My question is about the H-arm. I looked at the Getting to Grips document and there is no definition of H-arm. I understand the H-arm is a reference point but would it stay the same on every aircraft on an identical fleet? And if not, where would you find the specific aircraft's H-arm to enter the Airbus manual loadsheet in the top left box, page 121 in the Getting to Grips document? In this example above, is H-arm = 18.93 a generic figure or is that the one to use on the manual loadsheet?

Thanks for the replies,

Screwballs

john_tullamarine

31st Jan 2011, 04:57

when looking at the FCOM

One should keep in mind that this stuff tends to have all sorts of terminology differences across the Industry. As a result, it is necessary to maintain good housekeeping and cite which documents are being referred to ?

there is no definition of H-arm.

Generally one would expect H-arm to be the CG position of interest .. either of the whole aircraft or a given loading item ie a variable quantity. Numerous references in the AI document are consistent with this suggestion.

where would you find the specific aircraft's H-arm

.. in the descriptive material relating to the weight and balance manual (or similar document) for the Type or the loading system for the particular tail number.

in the top left box, page 121 in the Getting to Grips document? In this example above, is H-arm = 18.93 a generic figure or is that the one to use on the manual loadsheet?

For the location cited, the H-arm of interest is the particular tail number CG for the aircraft in the dry operating weight configuration (which can vary a bit so one needs to check the definition for the particular use).

The value 18.93m, as cited, is this DOW configuration value.

Note that you must read the term in context. It might be referring to the whole aircraft CG or it might be referring to the local loading CG position for a particular load item going into the aircraft.

One should keep in mind that this stuff tends to have all sorts of terminology differences across the Industry. As a result, it is necessary to maintain good housekeeping and cite which documents are being referred to ?

there is no definition of H-arm.

Generally one would expect H-arm to be the CG position of interest .. either of the whole aircraft or a given loading item ie a variable quantity. Numerous references in the AI document are consistent with this suggestion.

where would you find the specific aircraft's H-arm

.. in the descriptive material relating to the weight and balance manual (or similar document) for the Type or the loading system for the particular tail number.

in the top left box, page 121 in the Getting to Grips document? In this example above, is H-arm = 18.93 a generic figure or is that the one to use on the manual loadsheet?

For the location cited, the H-arm of interest is the particular tail number CG for the aircraft in the dry operating weight configuration (which can vary a bit so one needs to check the definition for the particular use).

The value 18.93m, as cited, is this DOW configuration value.

Note that you must read the term in context. It might be referring to the whole aircraft CG or it might be referring to the local loading CG position for a particular load item going into the aircraft.

Ajay SAXENA

24th Apr 2011, 11:03

HI

I found an interesting discussion on calculation formulate in progress. I would like to contribute on the same.

Before we know what is C , K or other terms are. We need to know basics of CG shift and law of movement.

Each aircraft when manufactured needs to specify various dimension i.e. distances. So, a arbitrary point is fixed by the manufacturer from where all calculations will be written. This reference point is called Datum Point.

Thereafter so we are suspending a load of 1000 kg at a longitudnal distance from the datum point. The impact of this load needs to be studied. So, arm x wt = movement. This was all types of loads are computed for movement. Now the movement put together becomes so big a figure which is difficult to handle. As such, a figure is selected which will reduce the big size. This is called C constant for which we need to rely on the engineer who has freezed the formula. The index movement is poistive K constant say 50 or 100 is selected.

Trust it gives some information to your field of discussion.

Ajay Saxena

I found an interesting discussion on calculation formulate in progress. I would like to contribute on the same.

Before we know what is C , K or other terms are. We need to know basics of CG shift and law of movement.

Each aircraft when manufactured needs to specify various dimension i.e. distances. So, a arbitrary point is fixed by the manufacturer from where all calculations will be written. This reference point is called Datum Point.

Thereafter so we are suspending a load of 1000 kg at a longitudnal distance from the datum point. The impact of this load needs to be studied. So, arm x wt = movement. This was all types of loads are computed for movement. Now the movement put together becomes so big a figure which is difficult to handle. As such, a figure is selected which will reduce the big size. This is called C constant for which we need to rely on the engineer who has freezed the formula. The index movement is poistive K constant say 50 or 100 is selected.

Trust it gives some information to your field of discussion.

Ajay Saxena