CG formula anyone ?
Moderator
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 !!
Moderator
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 ?
Thread Starter
Join Date: Aug 2006
Location: whichever galaxy i'm surfing in
Posts: 25
Likes: 0
Received 0 Likes
on
0 Posts
John could you have a look at this TCDS
page 54 type 310-304 (variant 1) ? ...it should be the one , 310F's were converted from pax versions ...thx
page 54 type 310-304 (variant 1) ? ...it should be the one , 310F's were converted from pax versions ...thx
Moderator
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.
Thread Starter
Join Date: Aug 2006
Location: whichever galaxy i'm surfing in
Posts: 25
Likes: 0
Received 0 Likes
on
0 Posts
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
Last edited by supernova.surfer; 10th Jun 2008 at 10:31.
Moderator
... 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.
Moderator
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.
Moderator
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 ...
Thread Starter
Join Date: Aug 2006
Location: whichever galaxy i'm surfing in
Posts: 25
Likes: 0
Received 0 Likes
on
0 Posts
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 ...)
Moderator
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
Thread Starter
Join Date: Aug 2006
Location: whichever galaxy i'm surfing in
Posts: 25
Likes: 0
Received 0 Likes
on
0 Posts
thx
Thanks for the offer to help further , in reply to my mail ....so......
Here's what i have followed so far...what i see is that sometimes at certain weights/indices the CG%MAC numbers which we can read off the Chart seem off by a tiny bit compared to what we can calculate , i'll try and recreate that situation and post the ZFW/ZFWI and the CG and CG%MAC when i stumble upon those numbers again.So from whatever progress we've made with your help in the project..herein lie my first hurdles/challenges , what i had hoped and intended to do (hopeful.... but not too far fetched ??).. is to superimpose a Plot based on x and y .. on a page with the graph serving as a background , x being indices and y the weights both of which my script already derives.
I could always only just print out the calculated CG's and %MAC's which would be a simple solution to the task on hand , but showing the graph is more challenging and its always fun to add some more learning curves .If it is concluded that it is in fact posssible to depict the graph , the question is about how to scale it i.e pixels vs Drafted Chart , i have not yet begun to plot various instances of x and y's with the program to see how far off it is and in which instances so.....assuming that ...we are...(well its not a purely personal project effort now
) ..able to somehow get the scale right )
so
Limits for the CG%MAC's ....to be honest i have'nt yet understood how to derive those...for a dynamic range of weights and indices that is
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
Moderator
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 ....
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
and I did study the flight envelope and I read FAA H8083 1A[ great pilot stuff]--
Great stuff JT--como siempre!
SuperNovaSurfer---whacha buidin'?
PA
Thread Starter
Join Date: Aug 2006
Location: whichever galaxy i'm surfing in
Posts: 25
Likes: 0
Received 0 Likes
on
0 Posts
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
ummm....(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...
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
ummm....(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...
Moderator
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 ....
Thread Starter
Join Date: Aug 2006
Location: whichever galaxy i'm surfing in
Posts: 25
Likes: 0
Received 0 Likes
on
0 Posts
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
Thread Starter
Join Date: Aug 2006
Location: whichever galaxy i'm surfing in
Posts: 25
Likes: 0
Received 0 Likes
on
0 Posts
Trim Datum
John ,
workin with a trim Datum of 26.67 is actually giving more accurate numbers e.g.
weight = 95000 kgs , index = -10
FS = -10000/95000 = -0.105263 + 26.67 =26.5647
CG MAC% = (26.5647-25.2132)*100/MAC = 1.35153 *100/5.8287=23.18
which is perfect as seen on the graph
the results match the graph at most combinations of wt/index
tried 140000 and -10 , 140000 and +10 , 140000 and -20 , +20 etc etc
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
Thread Starter
Join Date: Aug 2006
Location: whichever galaxy i'm surfing in
Posts: 25
Likes: 0
Received 0 Likes
on
0 Posts
optmum cg
OK looks lke the graph's almost done , although not that great a dsplay of graphics I thnk it'll do for now , wll let u know when ts done,workng on the STAB trim setting derivatons.While on the topic of CG s there anything such as optimum CG ?