RPP_FPGen SUPPORT THREAD

davidbernard · Post by **davidbernard** » 10 Nov 2008, 08:08

Rip,

This tool is MAGIC!

Thanks a lot for it!

David

RipPipPip · Post by **RipPipPip** » 16 Dec 2008, 18:20

You welcome!

I'm glad that somebody finds the tool useful, from time to time.

kungfuman · Post by **kungfuman** » 24 Mar 2009, 22:45

Oh dear...

Do you know what "Run-time error '13': Type mismatch"
might mean?

The output (normally a flightplan) that appears under the aircraft list shows the first line as expected: // AC#1,430,"AI-MiG29A KB701 INDIA AF"
the next line is: AC#1,KB701,100%,WEEK,VFR
but nothing more!

Any ideas what might be the problem?

Thanks in advance...

Ford Friendly · Post by **Ford Friendly** » 24 Mar 2009, 23:05

oops. ignore this post

Firebird · Post by **Firebird** » 25 Mar 2009, 06:44

I guess that the first questions I would ask are, have you used this before? and what version of excel are you using?

kungfuman · Post by **kungfuman** » 25 Mar 2009, 11:25

Hi,
I have used it successfuly before on my ms office excel 2003 sp3 edition.
By incrementally changing the 1st demo page aircraft entries to reflect the first two lines of my own project I have identified that the problem is with the
"Maximum range in nm or leg duration in min or h"
column. AFAIK, if entering a range restriction here in nautical miles, no unit symbol is required. Thus I have entered "430" (without " symbols) to represent a range restriction of 430 nm. After the macro runs and produces the error, the column in question displays "30", whereas when the macro works as intended these cells are normally deleted.
Previously, I used the program for transport aircraft flightplans with ranges exceeding 1,000 nm, so my next step will be to try increasing this parameter.
FYI my aircraft entry is (consecutive blocks representing consecutive column entries on the spreadsheet):

AC#nnn,cruise_speed,"name"
AC#1,430,"AI-MiG29A KB701 INDIA AF"

R (default) or F
F

"Reg No (or a Country name as in RegNoPatterns sheet)"
KB701

Flight No
0

"Traffic Percent (0-100) (nothing means 50)"
100

"IFR/VFR (nothing means VFR)"
VFR

"Probability Profile sheet name (nothing means 100% always)"
PP_Mil_Default

"Type of flying (STAR/ TOUR/ RAND, nothing means STAR)"
STAR

"Activity (0 -once a week, 100 -all possibilities)"
100

"Cruise altitude Min (nothing means 10)"
5

"Cruise altitude Max (nothing means 150)"
550

"Flight plan repeat? Nothing or YES"
<blank>

No of legs / day limit
<blank>

Maximum range in nm or leg duration in min or h
430

I have just tried different ranges and found that 0<range<9 and 1000<range work fine, but 10<range<999 causes the problem. As I mentioned, this was using the 1st demo page, so the only airport involved was EGOV.

Hope this helps a bit...

Firebird · Post by **Firebird** » 25 Mar 2009, 12:36

Yes it does help, very detailed info, thanks.

What I will do, when I get some time this evening, is to try and reproduce using the data you have given me, after reading the manual again

.

If anybody has an idea in the mean time feel free to jump in here.

Firebird · Post by **Firebird** » 25 Mar 2009, 21:21

OK it works for me, and I think I know what the problem is.

You identified the field that caused you the problem, "Maximum range in nm or leg duration in min or h" but I think that you may not have added the 'nm' after the 430. The field needs either 'nm', 'min' or 'h' for its calcs. A number on its own is not sufficient.

If you got away with it earlier then I guess you were lucky but that the outcome may not have been what you were hoping for.

By removing the 'nm' I was able to repeat the error message you received.

kungfuman · Post by **kungfuman** » 26 Mar 2009, 01:02

OOPS!!

Can't think why I thought no unit symbol was necessary...

Must have been the fact that I had been lucky and got away with it - the plans it produced seemed fine.

Thanks for sorting out my careless mistake!

Andy J · Post by **Andy J** » 11 Apr 2009, 16:24

Hello lads,

Having a problem getting this to work properly. I am using Office Excel 2007.

I have filled in all my airports, and my aircraft lines. I chose RAND for the type, and I am now getting "runtime error '6': Overflow.

Opening the debugger highlights this line, in the following snippet of the FPG_Randomize_Destination section in the code.

Code: Select all

          Case "nm"
            ' Calculate the Great Circle distance!
            glDistance = CalcGreatCircleDistance( _
              ActiveSheet.Cells(glICAO1_row, 1).Value, _
              ActiveSheet.Cells(curr_Dest_row, 1).Value)
            If glDistance > glFP_AC_MaxRangeOrLegDuration Then
              glRNDDest_Count = glRNDDest_Count + 1
              GoTo L_FPG_RD_TOUR_RND 'let's try again
            End If

This is the highlighted line in particular;

Code: Select all

              glRNDDest_Count = glRNDDest_Count + 1

Here is a sample of my aircraft line:

AC#1,450,"Russia 223 Letny Otrayd Il-76MD RA-76635" F RA76635 0 100 IFR PP_GA_Default RAND 100 150 380 3107nm

I must mention that choosing STAR, the macro runs fine.

Could anyone point me in the right direction? I would love to get these plans in the air!

Thanks, Andy

Andy J · Post by **Andy J** » 11 Apr 2009, 16:24

Ok, a little more info;

When I isolate the first airport on the list (CYOW), it wont run the macro, with the same error. I added in EGPK as from there the aircraft would be in range and could choose CYOW (Reasonable). This worked, but not in the way which I intended! The macro seems to ignore the range limit, which in this case I set at 3107nm. Where if it visits CYOW it should in theory first visit EGPK, I find it is going from the home base (Z25W) straight to CYOW! This should be well outside the range limit I set! Never once does it visit EGPK from CYOW, surely this can't be right?

Patiently awaiting a helping hand
Andy

Firebird · Post by **Firebird** » 11 Apr 2009, 18:31

OK Andy, I will try to help here but I should mention a couple of things firstly to diagnose I really need to see the full data going into it, so I have sent a pm with my address in. If you could sent it to me I can work on it.

Secondly, and this may be the bigger issue, is that I only have Office 2003 as I am obviously too cheap to buy the update

, and I suppose I must be too lazy to steal it as well

.
So I can check and try to reproduce the issue but it may be a version thing. I guess we will have to deal with that at the time.

Andy J · Post by **Andy J** » 11 Apr 2009, 18:56

I think I have an old copy of Office 03 somewhere.. reluctant to install that though!

Curiously enough, I have put EGPK at the start of the destination list, and it now works 80% of the time. Some of the routings look very strange however.

I don't suppose you know the Hayes / Harlington area do you? Might be easier to send the file by carrier pidgeon

The internet here has been bad all day.

Firebird · Post by **Firebird** » 11 Apr 2009, 19:19

Yep, I live slap bang in it, Harlington.

Firebird · Post by **Firebird** » 11 Apr 2009, 21:11

OK Andy, I think its quite easy.
The run-time error '6': is because the variable glRNDDest_Count is at 32767 when it tries to add one. The overflow is because the limit for an integer is 32767.

OK, that is far too techie. Basically, it has tried over 32000 times to check the distance between Z25W and CYOW. The reason is that it only checks the distance when using the RAND option.
The problem is, as far as you are concerned, is that RAND is a cross between STAR and TOUR. For TOUR you need to put the airports in order so in your case it never gets past CYOW no matter what you put later on.

So if you put EGPK as the first destination after Z25W it will always work.

Does this help?

Andy J · Post by **Andy J** » 12 Apr 2009, 04:12

Hello Steve,

Thanks for the testing! It does help, in some respects. As previously established putting EGPK results in a high success rate for the first few aircraft, however I have to try 10-15 times to get it to work. When it does, it gives me strange legs that are well over the range limit, any ideas?

Firebird · Post by **Firebird** » 12 Apr 2009, 09:51

What sort of strange legs, you only have Z25W, EGPK and CYOW? Only two will work properly with RAND, Z25W - EGPK and EGPK - CYOW.

What I did was set the percentage for EGPK to 100%, as the plane has to go there. Anything less and it will try to go to CYOW sometimes.

Andy J · Post by **Andy J** » 12 Apr 2009, 15:57

I have quite a few long range destinations in there, some in Canada, the United States east coast, Guatemala, China / Japan, and Sydney/Canberra. These are at the extreme end (6000+ miles from the home base). What I have done / am doing now is putting in strategic "stopovers" in as well, similar to using Prestwick for the Canadian / United States destinations.

I am quickly finding that the order of the airports list has a huge impact when you are using RAND. The stopover airports I am leaving at 100% probability, the others varied but with less chance. I am really hoping that I'll get a working macro now, with a bit more patience.

Thanks for all the help Steve, I'll let you know how it goes once I've figured out which layover fields I need to put in there.

Andy J · Post by **Andy J** » 12 Apr 2009, 17:00

Well, I'm unhappy to say I still can't get it to work.

The stumbling block is always the range limitation. I have made sure that it is possible to get to and from any airport in the list from the homebase, possibly routing through others. On occasions the FPgen does this quite well, what I don't understand is why it then decides it wants to send the aircraft 7000 miles accross the globe.

This unfortunately breaks the Macro.

A question for the developer.. why does it do that? It should be easy to say, hey this airport is out of range, finding another.

kungfuman · Post by **kungfuman** » 12 Apr 2009, 18:29

A little quirk of the program that I found was its overwhelming likelihood to send all aircraft through the first airfield in the visited airfields list if RAND is set, especially on their first leg - resulting in ai chaos at that location on Monday morning (if using the included military probability profile).
However, this was easily remedied by always copying the base airfield entry into this first line of the visited airfield list. So rather than an unwanted predominance of ai aircraft swamping whatever airfield I happened to have first on the visit list, I instead was able to produce better flightplans - interspersed with local training flights at the base airfield.

My only knowledge of the program is as a user, so what follows is just speculation on what I have observed or read in the manual.

The random function of RAND does not function in the random manner in which you or I might hope. It does not respect the probability indexes that one enters after the visited airfields entries. Rather, (according to the manual IIRC) it randomly chooses between STAR type or TOUR type flightplans. In practice, I found the output for each flight was in fact some abstract amalgamation of the two types. Because of this, I generally only use the macro for STAR flightplans, where the airfield probability indexes are respected.

My hope is that, if the program is ever further developed, it would be good to incorporate the airfield probability indexes into the RAND setting calculations. I envisage a tool whereby the user can create large batches of flightplans in one go - some STAR, some RAND - without the need for seperate runs for the different types. By way of example: If I wanted to send cargo aircraft both around the world and on more local flights, by using RAND I should be able to set the far off destinations at max probability, and the stopover destinations at whatever low probability I feel best reflects the use of the far off destinations. In effect, the stopover destination probabilities - as the gateways to the far off destinations (in conjunction with range settings) - could be used to control the flow to the far off destinations. Additionally, if an aircraft is flightplanned as far as a stopover destination, on reaching it the chances of continuing to the far off destination will be high. This of course means that range settings must be respected by the macro, otherwise it will send aircraft to the far off destinations regularly - simply bypassing the low probability gateways. I am therefore interested to see what the outcome of Andy J's problems might bring to light wrt the range control feature.

Another feature (more work again!) that would be nice: A way of controlling flightlevels dependant on range (with of course multiple substitute sheets to suit different types of operations) akin to Thomas Molitor's AITMv2.
But now I'm just being greedy...