John Dowson

Hi Hans, There is no change in this are between v7.0.3 and v7.0.4. You do not need to uninstall before installing a new version. If you do this, the default installation location will be C:\FSUIPC7 rather than your previous installation location. Therefore, it may be running with a default/newly created ini file rather than the one with your RUNIFs. Just run the installer, and it will then prompt you to uninstall before re-installing. So run the installer again, and make sure that you select the correct installation location. Please check this, and if thats not the issue, please attach your FSUIPC7.log and FSUIPC7.ini files. John

That can be safely ignored. WideClient always runs an Initial.lua file on start-up, if found in the WideClient.exe folder. See the WideFS User manual, section Lua plug-in facilities. One thing to note though is that you are running WideClient from a desktop folder. Did you mean to do this? Anyway, I'm happy that its now connecting. Such issues usually are caused by the network/sharing/firewall configuration. John

You should read this thread that you posted in, and also check the referenced threads, i,e,this one: I think you should be okay with the batteries, you can do quite a bit with the APU but I'm not sure about the full start-up sequence, fuels valves look ok but not sure about the pumps - you would need to try/test. I'm sure there are quite a few A320Neo (both with and without the FBW mod) dlvers that also use FSUIPC7, so maybe they can help. I could also give you a time-limited license for FSUIPC7 if you wanted to try for yourself - let me know. For Stream Deck, there is also an FSUIPC plugin available from a user contribution: John

Its not really a crash/CTD though is it? Looks like its hanging when exiting, or does it actually CTD as well? If its a CTD, is there any crash event in the windows Event Viewer logs? Your FSUIPC log shows that FSUIPC is waiting for P3D to call DLLStop to exit, so it looks like its closing down correctly. There's nothing in your log that shows anything that could prevent a correct and orderly shut-down. Does the same thing occur without FSUIPC running? If this only occurs in that one Orbx region, maybe try asking over on the Orbx forums to see if any one else is experiencing this issue. John

There is currently a known issue that is causing CTDs in MSFS when using SimConnect clients. There are various threads on this issue (both here and on the Asobo forums). Asobo are aware of this and its under investigation. The trigger seems to be related to the amount of data going through simconnect, and FSUIPC is a pretty heavy user.Some people have had success by disabling the reception of AI data in FSUIPC, by adding the following to the [General] section of your FSUIPC7.ini file: ProvideAIdata=No As FSUIPC7 is now a separate application (rather than an embedded dll), it should not cause MSFS to crash, and any MSFS CTDs should be reported to Asobo, with the windows event viewer details attached as well as the crash dump, if available. John

Re-run the installer and do not install the Auto-Start FSUIPC7 with MSFS component. If you do not see this component in the selection panel, you need to download the latest installer. You should be ok with that but you will have to manually start FSUIPC7. Once installed, please send me your InstallFSUIPC7.log file and I'll take a look. Are you using an MS Store install for MSFS or a Steam one? John

Its in your AppData which should be maintained during updates... Normally issues are created from the reverse problem - not manually deleting AppData files when updating! But each to his own!

Ok, glad its working. But from your description and image it doesn't make sense (and especially when taking into account Roman's comment) - your lvar macro is using set with no parameter (so expecting input from the assignment), and you assignment is to a toggle macro with no parameter....? Could you post your latest macro and ini files so I can take a look? John

No need to do this. The ini file is not touched when you re-install. A new one is only generated if none is found. This is due to the fact that the installer you used automatically added an entry in MSFS's EXE.xml file to auto-start FSUIPC7. If you are also using the old .bat file, that will also start FSUIPC7, so you are starting it twice. If you download the latest installer (still contains v7.0.4), the auto-start of FSUIPC7 via the EXE.xml is now optional. So download, re-install (don't uninstall or delete anything, or do anything with your FSUIPC7.ini) and uncheck the auto-start component. Also, on the last page, don't opt to install the new desktop link/bat file and continue to use your original one that also starts MobiFlight. Of course, thats just a suggestion. There are also various other methods you can use: - let MSFS start FSUIPC7, and start MobiFlight from the batch file - let MSFS start FSUIPC7, and add an entry in the MSFS EXE.xml to start MobiFlight - let MSFS start FSUIPC7, and use FSUIPC's [Programs] section to start MobiFlight Really, the choice is yours - try and use whatever works for you. Note, however, there can be problems with priveleges when auto-starting as each program should run at the same privilege level. Not usually an issue, but can be if one program needs or has been set to run with admin level privileges. Just a heads-up - don't worry about this unless you find that the applications won't start or communicate. John

So MSFS doesn't even start correctly when using FSUIPC7? Can you download the latest version of the installer and re-install (no need to uninstall first). When you install, uncheck the component Auto-Start FSUIPC7 with MSFS so that FSUIPC7 is not started by MSFS. Then, once MSFS has started, double click the FSUIPC7.exe to manually launch FSUIPC7, and tell me if it runs ok then. John

Try logging buttons & switches and events, then activate your button and you should be able to deduce what is happening from the log (use the open console menu entry to see in real time). If not, attach your log file here (with logging enabled) as well as your ini and I'll take a look. But it really isn't that difficult, and how you assign also depends on what type of button it is - is it a temporary on/off button, or a sticky button (stays on until you press again) or a switch )similar to a sticky button). For example, for a sticky button or switch, you should use the set command but with a parameter of 1 for the press (to switch on) and a 0 to release. Of course, it also depends upon the lvar. I presume it takes values 0 for off and 1 for on. You should check your documentation for that (or log the lvar values when its on and off to verify).

? Not sure what that means. FSUIPC should not have much of an effect on your frame rates, and I have not heard of such issues from any other PFC users. Are you using a default FSUIPC7ini file (i.e. not using a renamed one from a previous version)? If not, try with that (just delete or rename your current one). Note that I do not have any PFC devices so cannot really advise. Maybe try finding a post from another PFC user with the same device and post a question to them? John

Assignments are assigning Flight sim controls to your devices (axes and buttons) to control the aircraft. Lua is a programming language used for writing scripts to do more advanced controls. The user manual contains information on these, and if you look at the User Contributions section you will see various lua scripts people have written (and there are a bunch of examples included in the FSUIPC download). Check the FSUIPC7 documents, installed under an FSUIPC7 folder in your Windows Documents folder. Then you don't need an FSUIPC license really....! But thanks for buying one anyway 😉 John

Yes, and also show me the FSUIPC7.log file AFTER a CTD. The one you previously posted looks like FSUIPC7 was still running.... Your ini doesn't show anything - you have no assignments at all. Why are you using a registered version if not using assignments (or lua)? If it is the known CTD, which I suspect it is, the trigger seems to be related to the amount of data going through simconnect, and FSUIPC is a pretty heavy user. Some people have had success by disabling the reception of AI data in FSUIPC, by adding the following to the [General] section of your FSUIPC7.ini file: ProvideAIdata=No John

Is that the log file produced when MSFS crashes? Or was FSUIPC7 still running? If the latter, can you send me the FSUIPC7.log file when you experience a CTD. Can you also check the windows Event Viewer (after a CTD) to see if there is a crash even reported there, under Windows Logs -> Application, and if so please post the details. Also show me your FSUIPC7.ini file. Thanks, John

Are you sure that its FSUIPC7 crashing, and not MSFS crashing which would exit FSUIPC7? Please show me your FSUIPC7.log file so that i can confirm. Note that, as FSUIPC7 is now a separate application (rather than an embedded dll), it should not cause MSFS to crash, and any MSFS CTDs should be reported to Asobo, with the windows event viewer details attached as well as the crash dump, if enabled. There is currently a known issue that is causing CTDs in MSFS when using SimConnect clients. There are various threads on this issue (see the FSUIPC7 sub-forum). Asobo are aware of this and its under investigation. John

You are mixing things up a bit. If your argument string is a hex number (without the leading '0x', try this: function Arduino_Data(Arduino_Com_Port, datastring, length) if (string.find(datastring, "%d")) then xpdrcode=tonumber("0x"..datastring) ipc.control(65715,xpdrcode) end end John

Your installation log and exe.xml both look fine, so I don't know why its not starting. You could activate SimConnect logging - see this FAQ entry on how to do this: With this activated, you should see an entry and hopefully some errors when trying to start FSUIPC7, This is the entry in my SomConnect.log: You can also go back to the old method of starting FSUIPC7, from the batch file/desktop link. To do this, you need to edit the MSFS.bat file (located in your FSUIPC7 installation folder, C:\FSTools_FS2020\FSUIPC7) and change these lines: To i.e. uncomment the lines that add the delay and start FSUIPC7, and replace the INSTDIR string with your FSUIPC7 installation folder location. John

As always, we need to see your logs and ini files. Did you read the documentation as suggested? Did you try setting the ServerName and Protocol ini parameters? Or ServerAddress?

With that definition, you need to give your assignment to that a parameter of 1 to turn on, and 0 to turn off. If this is an on/off (1/0) lvar, you can use Toggle instead, i.e. 1=L:ALT_VS_SEL_ON=Toggle And just assign to that.

The entry is to start FSUIPC7. I do not know why this is not working for you. Do you get any errors from MSFS when trying to start FSUIPC7? Are you using an MS Store install or a Steam install? Can you attach your InstallFSUIPC7.log file please. John

Ok, strange though - I don't see this on my GF rotaries. And these would also trigger virtual button presses, no? So you would have the same issue using the lua script. But, as I said, you can use the IgnoreThese ini parameter to ignore the physical button presses if you like. However, the rotaries script was written to emulate slow/fast turning for rotary encoders with one button in each direction. Yours have two, so try programming just to the 'slow' button each direction. Also, check your button numbers in your script: Are your rotary button numbers really like that? From your example description, this should really be something like Rotaries = {22, 20, .. } (for rotary button 22 in one direction, 20 the other)

Best to install both x86 and x64.

Is that the error you get when you start FSUIPC7 manually, or when MSFS tries to start FSUIPC7? Anyway, P2A cannot connect if FSUIPC7 isn't running. First, try following these instructions from the README.txt: John

Yes, as the best way to determine if its a firewall issue or not is to (temporarily) disable them. Try each in turn and also both together (client and server PCs).