Yes the FSUIPC (3.60) log provides the answer, (see below). However after seeking advice concerning compatibility of recent versions of FSUIPC with the four older FSUIPC dependent applications I use, which can only pass their freeware key via the .key file, I have now been able to achieve backward compatibility using FSUIPC 3.81 which is also compatible with Plan-G. FSUIPC 3.9x fails to work correctly with some of the older applications I use and until I downloaded Plan-G I had never downloaded anything that failed its accreditation check within FSUIPC 3.60.

To satisfy my own curiosity, and to help you provide future support to FS9 users, I did disable first the key file, and then later the four relevant applications, to determine what the problem had been. The result of removing the .key file, with relevant older freeware still present and connecting, is an FSUIPC log which never progresses beyond a series of failures for the first application which becomes 'unaccredited software' in the absence of the .key file;

;
;
2085203     Illegal read attempt: offset 7B92, size 1 [M1]
2085203 ... Program or module not accredited for use with this unregistered FSUIPC
2085203     Illegal read attempt: offset 7B80, size 1 [M1]
2085203 ... Program or module not accredited for use with this unregistered FSUIPC
;
;

That loop never progresses beyond application 1 to FSUIPC dependent applications (2 to last); in which Plan-G is always last, because it requires manual connection. All internal Plan-G data is therefore set to zero. FSUIPC in effect 'shuts down' before Plan_G connection is attempted. If FSUIPC is 'looping' the Plan-G connect icon does not grey out and status is correctly indicated.

After disabling *all* such 'older' software, (which I had not done before during testing with any version of FSUIPC), so that the only FSUIPC dependent application that ever connects to FSUIPC 3.60 is Plan-G, the entire FSUIPC.log reads;

********* FSUIPC, Version 3.60 by Pete Dowson *********
Running inside FS2004(original release)
User Name=""
User Addr=""
FSUIPC not user registered
WIDEFS not user registered, or expired
Module base=61000000
ClassOptions: UIPCMAIN=FF7F, FS98MAIN=FF7F, FS2KMAIN=FF5E
WeatherOptions(Orig)=0000B027[0000B027]
InitDelay: 0 seconds
WeatherReadInterval=4
LogOptions=00000001
DebugStatus=0
     1264 System time = 09:49:17
     1264 C:\FS2004\
     1264 System time = 09:49:17, FS2004 time = 12:00:00 (00:00Z)
     9891 FLIGHTS\OTHER\FLTSIM.flt
     9953 AIRCRAFT\c172\Cessna172SP.air
    67580 C:\Users\Mike\Documents\Flight Simulator Files\0 EGHH Storch.flt
    67736 AIRCRAFT\Fiesler Storch\Fi156.air
    68641 Clear All Weather requested: external weather discarded
    70544 Advanced Weather Interface Enabled
    82899 Traffic File #48 = "addon scenery\calclassic traffic 1962\scenery\traffic_1962"
    83929 Traffic File #56 = "addon scenery\uk-kemble\scenery\traffic-kemble"
    84849 Traffic File #49 = "addon scenery\calclassic traffic 1962\scenery\trafficworld_1962"
   338819 Client Application: "Plan-G" (Id=4840)
   338819 C:\FS2004\Plan-G\Plan-G.exe
   338819    Product="Plan-G"
   338819    Company="TA Software.   http://www.tasoftware.co.uk"
   338928     Illegal write attempt: offset F068, size 1 [P4840]
   338928 ... Program or module not accredited for use with this unregistered FSUIPC
   340628 ### IPC Message processed in 1700mSecs ###

Note that by allowing your 'Connect Icon' to 'grey out' upon connection, but before product accreditation, while literally correct, creates a somewhat misleading 'status indicator' for bug hunting purposes since the established connection is terminated by FSUIPC 3.60

I deduce that FSUIPC 3.81 has Digital Rights Management (DRM) code that is compatible with the means of passing the freeware key coded inside Plan-G, but that FSUIPC 3.60 uses different DRM code with which Plan-G is incompatible.

You may need to advise FS9 users to obtain FSUIPC 3.81 in order for some other FSUIPC dependent applications to run alongside Plan-G, since like me they may use, *or may download in the future*, current FSUIPC dependent applications which, (for unknown reasons), are incompatile with FSUIPC 3.9 (possibly due to another DRM code change??).

FSAviator.

Using a later version of FSUIPC 3.x did not solve my problem, but maybe that is due to retained FSUIPC.key or FSUIPC.ini values??

In a recent thread entitled 'FS9 Fs connection' poster 'level 330' seems to have solved his Plan-G to FSUIPC 3.x connection problem by configuring his FSUIPC.key file differently, or via some 'required overwrite' after installing Plan-G.

He said;

<<ok that's good for me .... Fs Connect work! The solution is that I did not overwrite my old FSUIPC.key ...>>

1) Am I being thick? Is there a public key for Plan-G that I must add to the FSUIPC.key file in use? If so what is it?

If not, do you understand what 'level 330' did to his FSUIPC.key file that solved his problem?

2) Does Plan-G require specific settings in the FSUIPC.ini file?

In part mine reads;

ClearWeatherDynamics=Yes
OwnWeatherChanges=No
WeatherReadInterval=4
TimeForSelect=4
WeatherReadsFast=No

Those settings work for (latest) FSMETAR, but could those setting cause a problem re Plan-G weather searches?

FSAviator.

Thank you for taking the time to follow this up. Installed new dll. With no plan present, a/c unpaused on ground at EGHH, still using FSUIPC (mode) to connect, and weather reporting OFF, when I connect the entire log becomes;

>>>>>>>>>>>>>>>>>>>>>>>>>>

14:19:18 FS9 is installed
14:19:18 FS9 database is built
14:19:18 FSX is installed
14:19:18 Selected data set is FS9
14:19:21 Starting map
14:19:21 Initialisation complete.
14:20:27 RibbonButton_Click_ConnectFS
14:20:27 FSUIPC.Connect
14:20:29 Aircraft Position Report:

   GroundSpeed 0
   TAS 0
   VerticalSpeed 0
   TrueHeading 0
   MagneticHeading 0
   Latitude 0
   Longitude 0
   Altitude 0
   TurnRate 0
   Height 0
   Title
   Model
   ID
   Type
   FlightNo
   Airline
14:20:30 Requesting Nearest WX to aircraft
14:20:30 Station is     
14:20:30 Requesting Nearest WX to aircraft
14:20:30 Station is     
14:20:35 Aircraft Position Report:

   GroundSpeed 0
   TAS 0
   VerticalSpeed 0
   TrueHeading 0
   MagneticHeading 0
   Latitude 0
   Longitude 0
   Altitude 0
   TurnRate 0
   Height 0
   Title
   Model
   ID
   Type
   FlightNo
   Airline
14:20:41 Aircraft Position Report:

   GroundSpeed 0
   TAS 0
   VerticalSpeed 0
   TrueHeading 0
   MagneticHeading 0
   Latitude 0
   Longitude 0
   Altitude 0
   TurnRate 0
   Height 0
   Title
   Model
   ID
   Type
   FlightNo
   Airline

>>>>>>>>>>>>>>>>>>>>>>>

The map centres as above and weather is requested with no METAR station as target despite weather reporting OFF.

I think I understood your request and configured FS connection x 3 as requested with SimConnect as the means of connection. In each case Server Port/Pipe 0.

All three produce the on screen error message... Unable to connect ...(Is FS running) ...If you are using FS9... See the log for more details.

The log simply reads;

>>>>>>>>>>>>>
Usual stuff
14:53:17 Initialisation complete.
14:53:30 RibbonButton_Click_ConnectFS
14:53:30 SimConnect.Connect
14:53:30 SimConnect.Connect - Remote. Mode = IPv4 Server =  Port = 0
14:53:30 SimConnect Connect failed: BeatlesBlog.SimConnect.SimConnect+SimConnectException: Open: iPort value is invalid
   at BeatlesBlog.SimConnect.SimConnect.Open(String strAppName, String strHostName, Int32 iPort, Boolean bIsIPV6)
   at FS._SimConnect.Connect()
>>>>>>>>>>>>

or

>>>>>>>>>>>>
14:57:33 RibbonButton_Click_ConnectFS
14:57:33 SimConnect.Connect
14:57:33 SimConnect.Connect - Remote. Mode = IPv4 Server = localhost Port = 0
14:57:33 SimConnect Connect failed: BeatlesBlog.SimConnect.SimConnect+SimConnectException: Open: iPort value is invalid
   at BeatlesBlog.SimConnect.SimConnect.Open(String strAppName, String strHostName, Int32 iPort, Boolean bIsIPV6)
   at FS._SimConnect.Connect()
>>>>>>>>>>>>

or

>>>>>>>>>
14:58:52 RibbonButton_Click_ConnectFS
14:58:52 SimConnect.Connect
14:58:52 SimConnect.Connect - Remote. Mode = IPv4 Server = 127.0.0.1 Port = 0
14:58:52 SimConnect Connect failed: BeatlesBlog.SimConnect.SimConnect+SimConnectException: Open: iPort value is invalid
   at BeatlesBlog.SimConnect.SimConnect.Open(String strAppName, String strHostName, Int32 iPort, Boolean bIsIPV6)
   at FS._SimConnect.Connect()
>>>>>>>>>

The connect button does not grey out.

Resetting connection mode from SimConnect to auto just forces connection with FSUIPC 3.60 as at top.

I am unable to obtain a connection to FS9 using SimConnect with the supplied FS.dll and the settings shown in the logs above.

With an EGHH-EGKK PLN present in Plan-G and a/c positioned by FS9 at EGHH in accordance with the plan followed by Plan_G connection with FSUIPC 3.60 and your latest FS.dll

>>>>>>>

15:28:03 RibbonButton_Click_ConnectFS
15:28:03 FSUIPC.Connect
15:28:03 Aircraft Position Report:

   GroundSpeed 0
   TAS 0
   VerticalSpeed 0
   TrueHeading 0
   MagneticHeading 0
   Latitude 0
   Longitude 0
   Altitude 0
   TurnRate 0
   Height 0
   Title
   Model
   ID
   Type
   FlightNo
   Airline
15:28:03 Requesting Nearest WX to aircraft
15:28:03 Station is     
15:28:03 RequestWeatherAt: EGHH
15:28:03 Waiting for EGHH
15:28:04 Waiting for EGHH

The rest of the log is as in my first post with weather searches at each correctly identified waypoint that time out; except the log now concludes

15:28:10 Waiting for EGKK
15:28:10 FS9 WX EVENT NOT RAISED!!!
15:28:15 Aircraft Position Report:

   GroundSpeed 0
   TAS 0
   VerticalSpeed 0
   TrueHeading 0
   MagneticHeading 0
   Latitude 0
   Longitude 0
   Altitude 0
   TurnRate 0
   Height 0
   Title
   Model
   ID
   Type
   FlightNo
   Airline

>>>>>>>>>>


I have set both Plan-G and FS9 for automatic firewall access (if that is relevant).

I already had Google Earth installed and have no difficuty using it (if that is relevant).

The reason I use FSUIPC 3.60 is that later versions give a message that some of the freeware FS applications I use are not accredited for use with unregistered FSUIPC V and they fail to run, so I am reluctant to relinquish 3.60 other than for testing.

Plan-G also gave that error the first time I connected using 3.60.

I will run a test with most recent FS9 compatible freeware FSUIPC tomorrow, but will post only if it produces different results.

>

In accordance with the thought that my computer might lack required Visual C updates I did download and run vcredist_x86.exe from Microsoft. After rebooting and repeating the tests, the results were the same as above (when running FSUIPC as connection) and I suspect the relevant Visual C files were already in place.

FSAviator

As posted I had already tested with all four possible weather options. I repeated the test today with both weather options unchecked, and no plan loaded. The complete log result is then;

>>>>>>

16:07:30 PlanG constructor
16:07:30 executableFolder: C:\FS2004\Plan-G
16:07:31 Starting Plan-G, build 0.8.1.389
16:07:31 FS9 is installed
16:07:31 FS9 database is built
16:07:31 FSX is installed
16:07:31 Selected data set is FS9
16:07:34 Starting map
16:07:34 Initialisation complete.
16:07:48 RibbonButton_Click_ConnectFS
16:07:48 SimConnect.Connect
16:07:48 SimConnect.Connect - local
16:07:50 SimConnect Connect failed: BeatlesBlog.SimConnect.SimConnect+SimConnectException: Pipe Connection Failed ---> System.TimeoutException: The operation has timed out.
   at System.IO.Pipes.NamedPipeClientStream.Connect(Int32 timeout)
   at BeatlesBlog.SimConnect.SimConnect.Networking.Connect()
   --- End of inner exception stack trace ---
   at BeatlesBlog.SimConnect.SimConnect.Networking.Connect()
   at BeatlesBlog.SimConnect.SimConnect.OpenCommon(String strAppName)
   at BeatlesBlog.SimConnect.SimConnect.Open(String strAppName, String strHostName, String strPipeName)
   at BeatlesBlog.SimConnect.SimConnect.Open(String strAppName)
   at FS._SimConnect.Connect()
16:07:50 FSUIPC.Connect
16:07:51 Requesting Nearest WX to aircraft
16:07:51 Station is     
16:07:51 Requesting Nearest WX to aircraft
16:07:51 Station is     

>>>>>>>

FSUIPC connects, (the connect symbol goes grey and FS9(FSUIPC) appears), Plan-G fails to locate current unpaused aircraft position, the map centres on 0,0 and then Plan-G searches for weather with no identified METAR station as the object of the search. It times out and nothing else happens.

This is with Options/FS Display/Weather + Display Nearest Weather and Update Local both unchecked. 

If I load a plan prior to connection the map moves logically to centre on the midpoint of the plan. When I connect the map does not move to unpaused aircraft location, (= plan departure point), it again moves to 0,0 and displays the yellow aircraft symbol there while FSUIPC searches for weather at every waypoint on the plan. The search is logical, but yields no result, and Plan-G then times out with log error FS9 WX EVENT NOT RAISED!!!

The whole log (with a plan present and weather searching 'disabled' is as posted yesterday.

I am content to wait for v0.9. I just wanted to let you know that the reported problem is not FSX only. (Mis)identification of current unpaused a/c location preceeds weather searching, (and logically must), but I cannot prevent weather searching anyway using FS9 with FSUIPC 3.60 whether a plan is present or not at time of connection.

FSAviator.

Thank you for releasing Plan_G as freeware. I installed it yesterday (no prior install). Two monitors and no network. Plan-G is likely to become my VFR flight planner of choice. I don't wish to use it as a moving map GPS, but I would quite like to be able to review track compliance overlaid on Google Maps after VFR navigation in sim weather approximating VFR minima, and after 'dead reckoning' navigation over water, and above cloud during e.g. simulated WW2 (night) navigation in radio silence.

I am reviving this thread as I have the same problem in FS9 (UK version) running FSUIPC 3.60 (unregistered). Planning functions work as per manual, but aircraft always displayed at LAT 00 LON 00. FS9 is unpaused and my aircraft is on the ground at Bournemouth (EGHH) during connection to FS9, with or without a plan starting at EGHH loaded.

My log file shows that weather is not being found with, or without, a plan present. If I load an IFR plan EGHH to EGKK the log contains;

09:18:24 Setting window title
09:18:24 UpdatePlanWeather testing IsConnected
09:18:24 UpdatePlanWeather calling RequestWeatherForPlan
09:18:24 RequestWeatherAt: EGHH
09:18:24 Waiting for EGHH

many further attempts

09:18:25 Waiting for EGHH
09:18:25 FS9 WX EVENT NOT RAISED!!!

That repeats for each waypoint of the plan

Both FS9 and FSMETAR report the current EGHH & EGKK actual without problems.

Within Plan G ...Display nearest weather is 'ticked' or unticked and with 'update local' both ticked and not ticked. Result of 4 x possible WX option states is invariant re data logged.

If I connect with no plan present, or with the prior plan still present, and a/c still unpaused on ground at EGHH the log reads;

10:12:29 Starting Plan-G, build 0.8.1.389

then normal data logging until

10:12:52 FSUIPC.Connect
10:12:53 Requesting Nearest WX to aircraft
10:12:53 Station is     
10:12:54 Requesting Nearest WX to aircraft
10:12:54 Station is     

The aircraft location becomes undetermined uopn connection yet Plan-G keeps searching for weather despite now having no identified METAR station to search for. It seems to enter a continuing loop relating to 'weather search' and never progresses to any code modules relating to aircraft position symbol movement, with or without a plan present.

With the EGHH plan loaded or not, the Google map re-centres at LAT 0 LON 0 at 10:12:52 upon FSUIPC.Connect. With 'free' selected I can drag the map to show EGHH - EGKK of course, and flight plan track will display if the plan is loaded, but no real time flight path is created since Plan-G is still looking for weather south of Ghana and never moves on from that loop.

This may just be finger trouble (misconfiguration) on my part of course, but I do seem to have a 'stable' Plan-G installation and a 'stable' FSUIPC connection to FS9, and comma substituted for full stop issues do not arise in a UK version of FS9 configured logically for UK use.

I am running FSNavigator alongside Plan-G. It locates the aircraft and 'follows' it using FSUIPC 3.60. FSNavigator is payware and requires a supplied FSUIPC data key to use unregistered FSUIPC. Is running FSNavigator, (or other similar payware flight planners which use FSUIPC via a 'key'), alongside Plan-G a known problem?

Is there a way I can stop Plan-G from ever attempting to read weather so that it does not enter an unending weather search loop? I am happy to use FSMETAR to read the weather in use while using Plan-G to flight plan and (hopefully) conduct post flight plan compliance analysis.

Why does para 6.4.1 of the manual refer only to FSX re weather?

I will post later in a new thread re other minor pdf manual issue.

--

FSAviator