John Dowson

As I said: The log file is written to the same folder as where you ran the FSUIPC7.exe. If you don't know where that is, you can use the FSUIPC7 File -> Open Installation Folder... menu option. Please re-read my previous post. John

Sorry, but I can't help with the hardware/cable connection. Doesn't the device come with a serial cable, or can be optionally be purchased from Garmin? Maybe try asking on www.cockpitbuilders.com, or Garmin support. Once you have the device connected, the following web page can help you configure FSUIPC: https://support.flyelite.com/knowledge-base/what-settings-to-use-with-the-696796-gps-cable-in-fsxprepar3d/ Good luck! Regards, John

By the way, are you sure you are in the cockpit when you first attempt to connect Pilot2ATC? The Pilot2ATC User Guide does say: Do not attempt to connect Pilot2ATC until after you are in the cockpit in MSFS Could it be that you are just trying to connect too early? John

The log file is written to the same folder as where you ran the FSUIPC7.exe. You should use that FSUIPC7.exe to replace your currently installed one. The 'not connecting' log is from that new FSUIPC7.exe I attached above - your log shows this, and that you ran it from your Downloads folder: Whereas your 'connecting' log is from your installed v7.2.12 version: No you didn't, as your 'connecting' log shows you are still using this version. Please replace your FSUIPC7.exe in C:\FSUIPC7\ with the one in D:\Downloads. Then start MSFS/FSUIPC7, load an aircraft and try to connect Pilot2ATC. If it doesn't connect, restart FSUIPC7 and try again. If it then connects, show me your FSUIPC7.log file (which will be the successful one) and your FSUIPC7_prev.log file (which will be the previous one, produced when it failed to connect). Also, the usual reason that 3rd party programs cannot connect is that they are ran at different privilege levels. If Pilot2ATC cannot connect when FSUIPC7 is auto-started with MSFS, maybe try restarting Pilot2ATC, first with standard privileges and then with admin privileges. John

If you get the same issue, can you show me your two FSUIPC7.log files, one from when MSFS is started and Pilot2ATC fails to connect, and the other from when you restart and it connects ok.

Sure, I can add them. Any information on available hvars for any aircraft is always welcome, thanks. Note you can add them yourself (as I'm sure you are aware) but hvar files in the Community fsuipc-lvar-module folder location will get over written when you re-install. If you modify any provided hvar files, best to move them to the WASM persistent storage area (under your AppData folder - see the Advanced User Guide) where they will take precedence. John

I have no idea.... Some things to try: 1. Re-order the items - try starting AFC_Bridge first 2. If that doesn't work, try starting only AFC_Bridge: If that works, add the other items in, one by one. If it doesn't, maybe try uninstalling and re-installing ADC_Bridge. If it works then, try adding in the other entries. Otherwise, I suggest you try support for AFC_Bridge. John

Not that I am aware of. Do you know why Pilot2ATC does not connect to MSFS? Any error message? There weren't that many changes between 7.2.11 and 7.2.12, and none that should affect Pilot2ATC. Or was yout previous version not 7.2.11, and if so what version were you using? Maybe try with the attached version, which will be released shortly: John FSUIPC7.exe

Ok, good to know. Thanks for reporting back. John

Also, please update to the latest version of FSUIPC4, v4.976. Only the latest version is supported. John

What you posted (apart from being very difficult to read!) tells me that you don't have any axes assignments in FSUIPC - your [Axes] section is empty and you do not have any [Axes.xxx] profile sections. Are your assigning your axes in FSX? If so, why not try assigning in FSUIPC, then you can try what i have already suggested. If its a boxed version, have you updated with the SP! and SP2 service pack updates? If not, please do this. And please try attaching files, rather than pasting their contents. Just drop them into the box at the bottom of the text entry box. Also, the log file you pasted was pretty pointless. You haven't activated logging for Axes controls, as advised, so it doesn't contain anything useful. I suggest you try disabling controllers in FSX and try to configure your axes in FSUIPC, and we can go from there.... John

The hvar filename must be a substring match to the aircraft name, as reported in the log file, not necessarily the same, John

Did you actually try the solution before posting again? If not, you should have done, and reported problems (in your initial thread) if you had issues. And I also use AFC_Bridge. I am just trying to reduce the number of posts, especially for know issues with known solutions, that are documented as well as having plenty of support questions on the topic. I am finding that I cannot get any new features implemented in FSUIPC7 (and FSUIPC6) at the moment due to number of support requests (and MSFS/P3D updates), most of which are either already addressed in the provided documentation, or have been reported before. I'm sorry but it does get annoying responding to the same questions again and again, when I could be doing something more useful. I am locking this topic now, as I really have nothing more to add to this issue. I will update the documentation to make the solution to this issue clearer... John

I'm sorry, but I cannot advise on the compatibility of such a devices. However, it should work, but you may want PFC (or other such device users) to confirm. I can confirm that the PFChid64.DLL is compatible with both FSUIPC6 and FSUIPC7. John

Got it working....! The issue was that I needed to explicitly set the sim connection to be used by setting the following (WAPI) ini parameter: UseSimConnection=0 (for the WASMClient, this is set in the WASMClient.ini). Setting this for the client will then force it to use the default connection defined in the SimConnect.cfg file (located in the same folder as the application). If this is not done (or if a WAPI client doesn't set the connection using the setSimConfigConnection() method), then the default local connection (-1) is used, which is always local. John

Ok. But please consult the documentation and also search the support forum for similar questions/issues before asking for help. You could have sorted this out yourself using either method. John

I have been trying to get the WASMClient to run on a 2nd/client PC, but with no success. Not sure why. It should be straightforward according to this post: https://www.fsdeveloper.com/forum/threads/simconnect-from-a-remote-computer-to-msfs.448828/ John

The indexed entries under your [Profile.xxx] sections are the substrings used to match the aircraft title, so if the substring is contained any where in the aircraft title, that profile will be used. Have you read the documentation? Also see Appendix 2, as I said. John

I must have said this over 100 times now... FSUIPC7 is a separate executable/process, and in no way should it cause MSFS to CTD. All communication from FSUIPC7 to MSFS goes via the MSFS provided SDK. ALL MSFS CTDs should be reported to Asobo, with the windows event information included. It is impossible for me to trace the cause of an MSFS CTD, that is Asobo's job. John

In your FSUIPC6.ini, in the [General] section, change ShortAircraftNameOk=Yes to ShortAircraftNameOk=Substring You can then use substrings for your aircraft names in your [Profile.xxx] sections. Please see Appendix 2: About the Aircraft Specific option and “ShortAircraftNameOK” in the Advanced User guide. John

Please use the attached key file, valid until 30th November. John FSUIPC6.key

No, it won't. You need to quit FSUIPC manually. This has now been corrected in the attached version via a new ini parameter value. You need to set: DisableMSFSMonitor=Enum John FSUIPC7.exe

For those with this issue, I have added added a different method of determining if MSFS is still running, which can be used by setting: DisableMSFSMonitor=Enum Using this will revert FSUIPC to its previous behavior under windows 10 which will allow FSUIPC7 to exit when MSFS i closed. Available in the attached version, and will be released in the next version. John FSUIPC7.exe

LM are looking into this.

You should still be able to use them but would be trickier to set-up. Usually, for speed, heading and radio frequencies, you would assign to either up/down buttons, or up, fast-up/down, fast-down, for rotaries with two buttons in each direction. It doesn't really make sense to use axes for these - and there are no axes controls for such things. Probably the easiest way to set-up such rotaries would be via a lua script. You can assign the rotary to write its value to a (free for general use) FSUIPC offset. In the lua, which should be auto-started, you can monitor the offset using the event.offset function. When your handling function receives the value, you can then compare it to the previous value seen, and then send the appropriate inc/dec (or fast inc/dec) control depending upon whether it is greater or less than the previous value received, which indicates the direction. John