John Dowson

This depends on what sort of button you have and what it is assigned to. Can you activate logging for Buttons & keys, generate a short log file showing your issue (i.e. load the aircraft, push the button a few times, slowly, then exit) and attach that, together with your FSUIPC7.ini file.

Looking at your log, only the virtual rotary buttons 0 and 2 are being triggered, so only one button in each direction. This needs to be checked first - but I need to see your Rotaries.lua script. Can you please attach that. The lua log is difficult to interpret (and nearly impossible without the source!) so I will add some extra logging statements to that to log what I need and you can turn off lua debug logging. But it looks like 0 and 2 are the slow buttons, so no two consecutive button presses are being received within the time limit (100ms). Looking at the rotaries log, it seems the poll function is only called every 150ms or more, and if it processes a button press then its over 1000ms! This is extremely slow, and is why there are no fast movements detected. Debug logging will slow things down quite a bit, but it has also been reported that lua is running quite a but slower in FSUIPC7. This is something I need to look into further, when time permits. See One thing I commented there is that this only seems to occur when FSUIPC7 is auto-started by MSFS. So you could try waiting FSUIPC7 once it has been auto-started, and then start FSUIPC7 manually to see if that makes a difference. Please turn off lua plugin debug level logging when doing this, as that certainly slows things down, especially as you have so many scripts running. You can also maybe try tuning/increasing the FastTimeLimit to see if that helps. Also, your assignments are pretty much the same for each in/dec: - you have an inc/dec to the press and release of the slow button for each direction - you have an inc/dec to the press on the fast button in each direction I am not sure how these assignments would give you a fast ind/dec anyway, even if the fast buttons were working, You are sending one in/dec control in fast, and two in slow, so slow is actually quicker! Looking at the presets you have assigned to, e,g, FNX320_FCU_VS_KNOB_DEC : (L:E_FCU_VS) -- (>L:E_FCU_VS) this just substracts 1 from the lvar. For a fast action, you can define your own preset, e,g, FNX320_FCU_VS_KNOB_DEC_FAST as (L:E_FCU_VS) 5 - (>L:E_FCU_VS) which would subtract 5. Or you could parameterize this: (L:E_FCU_VS) $Param - (>L:E_FCU_VS) and specify the dec/inc value on the assignment. But you need to get the fast buttons recognised before thinking about this. John

Yes, it does seem to ne something else that is causing issues with the SimConnect connections. Setting MaxClients may help. The EXE.xml I provided just starts FSUIPC before the other add-ons, but this may not work as the others may still connect first. What you could also try is starting FS Realistic via FSUIPC - see the section Programs: facilities to load and run additional programs in the Advanced User guide. The log looks ok, but I wouldn't recommend a setting of 4 for DetectToConnectDelayAuto, and your log does show some re-connections. I would not recommend any setting below 20, and usually advise 30 as the minimum. John

This depends on whether the new one is assigned the same GUID as the old one or not (and if the names are the same)). If so, no issue, but it will probably be assigned a new GUID, in which case you will need to manually edit the GUID of the existing letter in the [JoyNames] section of your FSUIPC7ini file (for your old throttle), and delete the new letter entries. Also change the name if that has changed. John

I will look into this but I a, rather busy at the moment, so it may take me a few days...probably next week sometime or possibly later... There was one possible change that could cause this - from the changes.txt file (and FSUIPC history document): So you could try that. But before that, please check the build date of your 7.4.18 version, in the 1st line of your FSUIPC7.log file. If this says 1st November, please re-download and re-install. It should say 3rd November. The initial release was accidentally built against the MSFS2024 SDK, and I corrected this the following day. You may need to clear your browser cache to re-download (otherwise the old cached version will be downloaded), John

The file you attached is called Simconnect.ini.log whereas it should be called just SimConnect.ini (i.e. remove the .log)- and it should be under C:\Users\xxx\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache. Check your SimConnect.xml file as well (same location), and make sure the MaxClients entries are all set to 128 - if not, update them. What is this entry for in your EXE.xml: ? Also please try the attached EXE.xml - I have moved the FSUIPC entry to be started before the others, John exe.xml

Auto-tuning continually monitors for connection errors/timeouts during start-up, and if any anomalies detected it will flag auto-tuning to be ran on the next FSUIPC7 auto-start. So you must have had a value set that caused some issues, and when auto-start ran the next time it either took a long time to get to the main menu, or possibly you passed the main-menu state before FSUIPC7 connected, and so a large DetectToConnectDelayAuto time was set. You can prevent auto-tuning doing this by setting: StartUpTuningDoneVersion=-1 If you do this, probably also a good idea to increase the initial stall time, i.e. also set InitialStallTime=30 John

I also need to see the Rotaries.lua script, and the Fenix A320.ini - the ini file used with the aircraft you are using, which is "Airbus A320-200 CFM Orbit Airlines D-AOAW". And the slow turns are working but the fast ones not? Was this previously working for the same aircraft? Note that it may work in one aircraft but not another, depending on the controls you are using. Especially with (complex) add-on aircraft as many of the standard FS controls (or FSUIPC offsets) don't work, and you need to use other methods, such as custom controls, presets, input events, etc Presumably you are using the Rotaries.lua to set different virtual buttons for slow/fast in each direction, and have assigned the controls to these virtual flags, no? And it is far easier for you to debug such issues, as you can see what is happening in real time when you turn the rotaries. Are the virtual button flags being set/triggered? Do you have assignments to these virtual buttons, and are they being sent? But I can take a look to see if I can see anything. Please also activate FSUIPC logging for Buttons & Keys and Events, and send me the complete set of files.

This is because you have a very large DetectToConnectDelayAuto set: Auto-tuning is gradually reducing this: but it will only reduce by 10 seconds at a time. This high value was probably set via auto-tuning when MSFS took a long time to load (for some reason). Try manually setting that value to 30 in the [General] section of your FSUIPC7.ini file. If that is too low, auto-tuning should increase this to the correct value, which will take effect on the next restart of MSFS. See the Advanced User guide section Auto-tuning of initial start-up ini parameters on how this works, or the following FAQ entry: John

For help with presets, please use the MobiFlight Discord server on the MSFS2020 channel.

Can you please re-download 7.4.18 and re-install and try again please. The build date should read 3rd November, not the 1st. Please check this. You may need to clear your browser cache to download the version again. The initial release of 7.4.18 was accidentally built against the MSFS2024 SDK, but I correct this a day later and re-uploaded but didn't change the version number. Sorry about this. John

Please show me this file as well: C:\Users\marty\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\EXE.xml Yes, but it connected and was working when you did this, although it took far longer to connect than it should. I do not know or understand why simconnect is either not responding or taking a very long time to respond, I can only think that this is due to other simconnect clients, which is why I would like to see a simconnect log file (as this shows all simconnect activity. Not sure why you attached that log file - just shows that you exited FSUIPC after 14 seconds, and there is no additional logging. For the time being, please run with the logging console open (Log -> Open console) and monitor the messages, and only exit FSUIPC if you see that it cannot connect after a minute or so. Also please set the following options in the [General] section of your FSUIPC7.ini file: InitialStallTime=45 DetectToConnectDelayAuto=20 StartUpTuningDoneVersion=-1 TestOptions=x800 This will reset those parameters and prevent auto-tuning changing them (as well as setting the additional logging), This issue seems very different from your original issue. Did this connection problem start recently?

That seems very quick...so when FSUIPC tries to connect, MSFS is in the main menu state. I don't understand why it cannot connect then... Are you doing anything with MSFS, or is it just waiting un the main menu? The log file you attached shows that FSUIPC eventually connected, but took over 3 minutes, and you manually quit FSUIPC after 6mins 25 seconds. That is strange - I don't know why it would do that... You could maybe try with FS Realistic not running 9or auto-started) to see if that makes a difference. Could you show me / attach your EXE.xml file so I can see what else is being started - the location of this file will be logged in your InstallFSUIPC7.log file. I think you will need to activate logging in SimConnect (see that FAQ entry I referenced above) and show me a SimConnect.log file. Once activated, start MSFS and ley everything auto-start. Leave it for a few minutes, and if FSUIPC doesn't connect, exit MSFS and show the the SimConnect.log file (or files), together with your FSUIPC7.log file. They will be very big and will need zipping/compressing. Even after that they will probably be too large to attach and you may need to use a file-exchange service to show it to me. Can you also add the following to the [General] section of your FSUIPC7.ini file please: TestOptions=x800 That will add additional logging around the start-up and connection.

Please show me /attach your FSUIPC7.log file from when you get your issue and close FSUIPC (and before you restart),

What do you mean by this? Do you not see the FSUIPC splash screen when FSUIPC starts? Can you not see the main window after pressing Alt+F? The log file you attached is again showing that FSUIPC cannot connect to MSFS. But I don't understand why it stops after 4 attempts. What other add-ons are you using? Once MSFS starts, how long does it take to arrive to the main menu state? Can you time this please - do the following - start MSFS and time how long it takes from when you see the MSFS window appear (or, better, from when you see the FSUIC splash screen) to when it gets to the main menu state. Also, when FSUIPC starts (i.e. after you see the FSUIPC splash-screen) exit/quit FSUIPC - do this by opening the main window (Alt + F) and then select File -> Exit. - Once MSFS started and has reached the main menu, manually start FSUIPC7. Does it now connect? Exit MSFS and show me the FSUIPC7.log file from this test, - Open the FSUIPC7.ini file and set the DetectToConnectDelayAuto ini parameter to the approximate number of seconds it took MSFS to start and arrive at the main menu. Also set the InitialStallTime ini parameter to 45. - then restart MSFS. Does FSUIPC7 now start and connect ok? Show me the FSUIPC7.log file from this test. If this issue persists, then I may need to see a SimConnect log file, as it seems that FSUIPC is unable to obtain a simconnect connection for some reason. To generate a SimConnect log file, see the following FAQ entry:

No - they would be further away. The max value should be 16383 and the min value -16485. I do not understand what your 'mid' value is though - is this the value when your axis is roughly in the mid position? What do you mean by ' isn't consistent'? You can easily calibrate for the max and min values, and the centre values are only really relevant for certain axes (elevator, aileron, rudder), and you can calibrate for the off-centre mid values by using a calibration slope. Well, you would probably get the full range for a new controller, but you should be fine with those axes values really. Are you having any issues, and if so what? You can also try calibrating your devices/axes in windows (game controllers) first - this may improve the axis range values seen by FSUIPC. John

That should be running as it is in your auto section. But if you think you have an issue with a lua script you should set Lua debug logging, and as you seem to have quite a few lua sript running you shout also set to log lua plugins separately, and each running lua script will be debug-logged to a separate file. Your upload limit will increase the more you post. If its still too large after compression, you will have to use one of the free file transfer services, e.g. filetransfer.io or wetransfer.com. Make sure you also include your latest FSUIPC7.ini file.

I think you mean 'write to' or 'update' not 'configure'. It is FSUIPC that configures the offsets... The easiest way is to update an offset is to use the FSUIPC-added controls that write/update offsets, probably you want to use Offset Byte Set. But your device needs to be seen/visible to FSUIPC to use assignments. Otherwise it may also be possible via lua if its a an HID-type device. Or of using the FSUIPC SDK (in your own software), you can just write/update the offset directly. John

Right-click and select Save as... But here it is: FSUIPC460Francais.zip

By the way, when you change to Files it will move your profile assignments to separate files. If you change back, it does nothing, and so FSUIPC will NOT see your profile-specific assignments.

You also have two [LuaFiles] sections....that can cause issues as you don't know which is being used, and one changed the LuaPath. And the files are assigned different numbers. Determine which is being used and remove the other. You should NEVER touch that section - it is maintained by FSUIPC.

I don't understand your ini...you are using profiles, but it looks like you were previously using profiles-in-separate-files, but no longer as you have: UseProfiles=Yes rather than UseProfiles=Files So most of your profiles are empty, except for your JF Hawk profile. Switch back to using Files to restore your profiles. Also, update your profile aircraft names to use substrings. e.g. change to and do similar for all your other aircraft profile names. When you add an aircraft to a profile, you should always edit the name for the shortest string that will catch all variants and no others, John

Why 'again'? This is your 1st post... What has changed? Please show me/attach your FSUIPC7.log file.

No need. A knob us just a collection of buttons (usually either 1 or 2 in each direction) or an axis. From your ini, your knobs use buttons. Please see my previous reply. You have assigned to the standard FS controls. For PMDG aircraft, use the custom controls. Try logging events (with the logging console open) and turn the knob/knobs you want to replicate. You should see Rotor Brake controls logged with the parameter indicating the function and mouse control applied. You can also use/assign to these - to use the PMDG custom controls via the Rotor Brake control, see That is deprecated as the other method (via custom control numbers) is preferred, but it is still valid and maybe easier to use for inc/dec assignments (which usually correspond to left/right mouse-clicks on the VC control). John

When using PMDG aircraft, many if the standard FS controls won't work - you need to use the PMDG custom controls - see John