John Dowson

The following license is valid until 5th May: FSUIPC7.key

But that is now an old and unsupported version. You should use 6.1.0 (or 6.1.1a), which are the latest supported versions. There is no change to GF handling in these versions from 6.0.14.

No! You cannot use the same lvar more than once in a macro, as the lvar name is also the macro name. Therefore there is no way to distinguish between those entries. If you want to do it that way (i.e. multiple macros on the same lvar), you would need each macro definition (using the same lvar) in its own file.

The GFDev64.dllv should be placed in your FSUIPC6 installation folder, wherever that is. If you don't Know, you can open that folder using the Open Folder button in the logging tab. Check (or post) your FSUIPC6.log file - there will be a message in that file if the GF dll is found and loaded, and show the devices detected, e.g here's mine:

Your FSUIPC7.log shows that FSUIPC7 was running and connected to MSFS ok: So FSUIPC7 is running and connecting ok. If you open the FSUIPC7 main window it will show that it is connected. As Pete says, make sure you are ready-to-fly and check you at running Pilot2Atc at the same privilege level (and maybe check the Pilot2ATC logs). As for why FSUIPC7 is not starting with MSFS, can you show me this file please: C:\Users\BD3B484275CE462B\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\EXE.xml

But in normal shutdown, there are only termination messages. The "warnings" are only in your debug log: 112203 **** DevCom read/write threads still running - will exit anyway but could cause issues... 112500 **** DevCom Read thread terminated Anyway, I think things are ok as they re for now.... Cheers, John

Normally, or when in debug?

And neither the event.param

You could also explicitly terminate the thread yourself in your HandleShutdown function - just add an ipc.exit() call to the end.

It has the same timestamp, so is just something that occurred around the same time, before the cancel completed. Its not an issue.

Note that when you see this: in the log: This indicates that the thread didn't close correctly, and the initial termination code didn't stop the thread, and so was eventually killed by the main thread (or the DLLStop thread). This can cause issues if the com thread is not fully closed, but I haven't seen such an issue (with the updates in 6.1) so far....

Yes, if you debug it will increase the latency. But I'm not going to adjust for this - and it still closed down correctly anyway, so I don't see an issue.

Yes, but that maybe because you have TimeForLuaClosing=5 still set, which is the time betwwen these messages: 90688 Waiting for lua threads to process termination event... ... 95688 Lua threads being terminated: The com.close is done hbetween these log messages: 90688 LUA.1: Shutting down USB device hnd=1 ... 91328 LUA.1: USB Device disconnected So is taking roughly 0.65 seconds. You can try reducing the TimeForLuaClosing back to 2, or maybe even try 1. Also, for such issues, its also a good idea to enable logging for 'Extras', as this will then log the thread that is producing the message. Most shut-down issues are thread & timings related. The thread is still being killed later though, which is a bit strange, but at least the com has closed so this isn't an issue. However, I did reduce another timing that may have caused this - I will increase again slightly when I release this. Thanks for you help on this, John

Then it sounds like either FSUIPC was not installed correctly or it is not auto-starting with MSFS. First, try starting FSUIPC7 manually by double-clicking the FSUIPC7.exe. If it runs ok you will see a splash screen and then the icon will appear in your system tray. If it doesn't run, you should get an error, and if thats the case you need to re-install the VC++ redistributables. Instructions for this can be found in the README.txt that is in the zip you downloaded. If FSUIPC7 runs when you manually start it, there is a problem with the auto-start. If thats the case, I need to see your InstallFSUIPC7.log and your EXE.xml, whose location can be found in the Installation log.

No, not necessary. Please try the following instead: FSUIPC6.dll

and also try this one (and show me the log): FSUIPC6.dll

The file name has to be a substring of the aircraft name/title. The full aircraft title is "TBM 930 Asobo", so TBM930 doesn't match - you need the space, so use "TBM 930.hvar".

You can read/write to offsets using the free version. If you want to assign to them, you need the registered version. So that is fine with the free version. and this would require the registered version.

No - no way to currently access lvars via simconnect. I don't know Air Manager - can it access fsuipc offsets? If so, your best bet is probably to write the lvar values to free/user offsets, and then read them back from Air Manager using the offsets. If Air Manager doesn't use FSUIPC, then I'm not sure how you can do this - maybe using files, but that would probably be problematic as well as rather slow...

and also please try this one (same ini settings): FSUIPC6.dll I would like to see the logs for both dlls please....

Could you temporarily re-enable your event.terminate and try the attached dll please (with TimeForLuaClosing=5 set), and show me the log file after closing: FSUIPC6.dll

Yes, thats the new warning I added in 6.1. I would use this for now (i.e. no event.terminate), and I'll look into why that lua delay isn't working and get back to you.

Yes, looking at this now... Did you try this?

Interestingly, I checked my INI and the parameter was already there... set to 2. Yes, interesting... Ok. After you have done that, could you re-enable and change that parameter to something quite large, say 5 (seconds) to see if that makes a difference, and show me your log file afterwards (or the closing extract) so I can see if that has any affect. If not, I will look into it....

👍