John Dowson

Note also that your DetectToConnectDelayAuto ini parameter seems to be set far too low: From that log extract, you should be using a value of 262.

Please see my previous response: You have LvarScanFrequency set to -2.

Nothing will be logged, as there is no specific facility to log lvar changes. You need to list the lvars again when the rudder is at the full deflection (not after) to see the value when fully deflected. Did you do that? Otherwise, you can log an lvar by adding it to an FSUIPC offset and then log the offset changes. This logging was to check that FSUIPC7 was sending the lvar update request when using the Add-ons->WASM->Set Lvar menu option. Did you try that? What was logged? These would be the FS control/event that are logged. You have already tried assigning to the FS controls which doesn't work, so you can forget that. Try the following: 1. Add the following to your FSUIPC7.ini file: [LvarOffsets] 1=L:RudderPos=F0xA000 This will add the lvar RudderPos to offset 0xA000 as a 4-byte/32-bit floating point number. 2. Start MSFS and FSUIPC. Then open FSUIPC, remove all logging options except for Events and Input Events, then go to Log->Offsets, and add logging for offset 0xA000 as FLT32, and make sure to check Normal log file. 3. Load your aircraft, move the rudder through its full range, from neutral to left full, back to neutral then right full and back to neutral, List the lvars (Add-ons->WASM->List Lvars) and then exit FSUIPC7 and show me / attach the FSUIPC7.log file.

Also note that the preset assignments shown by AndyCYXU in the image above are assigning to both the press AND the release of a button. This is ok if using a switch or sticky button, but if using a standard momentary button then the press will be followed by the release, and so this may switch the warning off and then back on again, although as I don't have the Fenix I cannot confirm this. If this is the case, you need to either change the presets to toggle the lvar, or use separate buttons/keys for the press and release events/presets.

Sorry if you interpreted that way - I am certainly not scolding you, but letting you know that I cannot help you if you don't provide any further information apart from saying 'it doesn't work'. I get a lot of posts saying 'X isn't working, please help'. Just saying 'it isn't working' is just not enough for me to help - I ALWAYS need more information. Please see There are many reasons why something 'doesn't work'. If you want help, you need to provide more information. If you have no idea what the FSUIPC7.ini file is or where that is located, then please at least read the User guide. You should always consult the documentation BEFORE asking for support. And if using presets/lvars/hvars, you should at least read the WASM section in the Advanced User guide, which should tell you everything you need to know about using presets. John

I don't think so but am not sure - I will take a look later. This is standard MSFS functionality and not restricted to the Fenix. There doesn't seem to be a way of doing this via FSUIPC at the moment. However, there is a specific free add-on for managing pop-up panels which also allows keys to be assigned to show/hide such panels: MSFS Pop Out Panel Manager. See https://flightsim.to/file/35759/msfs-pop-out-panel-manager John

Ok, then you can probably use that... Was the 0 value when the rudder was at the central position? If so, you need to determine the values for maximum left and right deflection: move the rudder full left/right, and list the values again. What is the update value when fully deflected? 1193 is just the id of the lvar and can be ignored. The 'Set' button always works and is never disabled as far as I remember. What values did you try and set? If you set WAPI debug level logging (Log -> WAPI -> Debug) then you should see the control to update the lvar logged (in the logging console). It is helpful to determine the max/min values for this lvar, and then try setting those values, as well as 0, and see if the rudder moves/reacts. If this lvar is writeable and working, I can show you how to use this to control the rudder, but I need to know the max/min values for full right/left deflection. If 0 is the rudder centre position, then the lvar will probably have a range of either -1 to + 1 (as a decimal), or -100 to + 100 (as an integer).

@MD80PROJECT Sorry for the delay. I have tested all those offsets and they are certainly available for general use, so you must either be already using those offsets or have something else wrong. As I said, logging should help. Here is the lua script I am testing with (also attached below): local offset = 0x6700 local lvar = "L:YokeLeftVis" local loggingActive = false -- change to true for additional logging messages local lvarValue local offsetValue -- event function to update offset when lvar is updated function lvarUpdated(lvarName, value) lvarValue = value if offsetValue ~= lvarValue then if loggingActive then ipc.log("lvarUpdated: Updating offset with lvar value " .. lvarValue) end ipc.writeUB( offset , lvarValue) elseif loggingActive then ipc.log("lvarUpdated: Not updating offset as already has correct value") end end -- event function to update lvar when offset updated -- NB: to assign to update the offset, use the control: -- Offset Byte Togglebits -- using the offset used and a parameter of x1 function offsetUpdated(offset, value) offsetValue = value if offsetValue ~= lvarValue then if loggingActive then ipc.log("offsetUpdated: Updating lvar with offset value " .. value) end ipc.writeLvar(lvar , value) elseif loggingActive then ipc.log("offsetUpdated: Not updating lvar as already has correct value") end end event.Lvar(lvar, 100, "lvarUpdated") event.offset(offset, "UB", "offsetUpdated") ipc.log ("lvar2Offset script running using lvar '" .. lvar .. "' and offset " .. offset) This script allows the offset to be updated to set the lvar, and any changes to the lvar will update the offset. Note that I am only using a byte to hold the lvar value - this is all that is needed for lvars that have values 1/0. John lvar2Offset.lua

There seems to be an issue that can prevent key presses being received by FSUIPC7 from MSFS that will stop both key assignments and 3rd-party hot-key assignment from working. If you have an issue with key assignments or hot-key assignments (from 3rd party add-ons) not working, then please first check/verify if key presses are being received by FSUIPC7. To do this, activate logging for Buttons & Keys (Log -> Buttons & Keys), open the FSUIPC7 logging console (Log -> Open Console), give the keyboard focus back to MSFS (i.e. click on the MSFS window) and then press any key. In the logging window, you should see the key press/release events logged, such as the following: If you do not see any key presses logged, then key presses are not being received by FSUIPC7 from MSFS. ** NB: you should have an aircraft loaded and ready-to-fly when testing for key presses, as they are not requested until the first aircraft is loaded and ready-to-fly ** To correct for this, you can perform one of the following operations: 1. Disconnect from MSFS (MSFS -> Disconnect) and then re-connect (MSFS -> Connect), or 2. Exit FSUIPC7 and restart This seems to be caused by a timing issue, when the SimConnect calls made to request the key presses are accepted (i.e. no errors produced) but are not acted upon. To correct for this, you can try increasing the delay from when MSFS is detected by FSUIPC7 to when it tries to connect. To do this, you need to increase the value of the DetectToConnectDelayAuto ini parameter, located in the [General] section of your FSUIPC7.ini file. Locate this parameter and increase its value by 5 (seconds) and try again (i.e. restart MSFS, let MSFS start FSUIPC7 and then test for key presses as shown above). If you get the same issue then repeat, i.e. increase the DetectToConnectDelayAuto ini parameter by 5 and try again. Once you have determined the correct value for the DetectToConnectDelayAuto ini parameter, you can then set/update the StartUpTuningDoneVersion ini parameter to -1: StartUpTuningDoneVersion=-1 This will prevent FSUIPC7 from further automatic tuning of this parameter,

There is no point just saying that it is;n't working. If you want help, please explain what you are doing and show me your files - I need to see your FSUIPC7.ini file, so that I can see your assignments, and your FSUIPC7.log file which shows me what is happening, and preferably generated with logging for Buttons & Switches activated. Have you used presets before? Are other presets working? Have you installed and activated the WASM? Have you read the documentation on using presets?

No need to attach if it is now working. However. you should not need to restart for this to work, If you find that key assignments are not working, exit FSUIPC7 and then attach the log file. The log file is in the same place as the ini, in your FSUIPC7 installation folder. If you can't see it, you have Windows Explorer set to hide the extension of known file types. There does seem to be an ongoing issue where key presses are sometimes not being sent from MSFS to FSUIPC7. If this happens, you can try disconnecting and re-connecting to MSFS (using FSUIPC7's MSFS menu) or restarting FSUIPC7. This also seems to be due to the timing of when FSUIPC7 connects to MSFS when auto-started, so you can also try increasing the DetectToConnectDelayAuto ini parameter by 5 (seconds) or so.

For lvars, use Add-ons->WASM-> List Lvars - do any look like they control the rudder? If so, you can try setting them using Add-ons->WASM->Set Lvar. For Input Events, use Log->List Input Events to see what is available. If either an lvar or an input event is available, I can help you assign to use these. Ok, then you need to try lvars and Input Events. If its also not possible in MSFS, you should ask about this on the aircraft support forum.

Can you please attach your files and not screenshots. I need yo see your FSUIPC7.ini and FSUIPC7.log files, the latter generated with logging for Buttons & Keys and Events activated: start MSFS and FSUIPC7, activate the logging (Log->Buttons & Keys, Log->Events), load your aircraft, test the assignment then exit FSUIPC7 and attach those files. John

The log file shows the axis controls being sent and applied correctly, so it looks like this aircraft is not responding correctly to this rudder control. Try assigning using Send direct to FSUIPC calibration to see if that makes a difference. Did you check for any lvars or Input Events that could be used to control the rudder? Does the rudder function correctly when assigned in MSFS?

What was the issue? Seems like there was a space before the folder name (" Fsuipc") which could cause issues...

Did you try the preset FNX320 Glareshield Master Warning Captain Button Press? That preset uses the lvar L:S_MIP_MASTER_WARNING_CAPT. If that us not the correct one, you need to check to see if there are any events or lvars that you can use. You can use FSUIPC's logging facilities to assist with this, As I do not have this aircraft, I cannot really help much with this. You can also post of the Mobiflight Discord server, in the MSFS2020 channnel - this is the place to ask about presets for specific aircraft functionality.

Ok. If the implementation of this AP is different from the real thing, I cannot do anything about this. Try asking about this on the support for the aircraft.

Sounds like FSUIPC7 wasn't auto-started. Please show me / attach your InstallFSUIPC7.log file. For any and all issues with auto-start, see the FAQ entry:

1. You are still using 7.4.11 - please update *Ok, I see you posted for an issue with the update - I have responded there 2. You did not activate the required logging so the log file is useless 3. Your ini file is now empty except for the one assignment to the rudder?

You should always attach files after exiting FSUIPC7, not before. Try zipping/compressing. You are also using an old and unsupported version of FSUIPC7, 7.4.11 - please update to the latest version, 7.4.16. Looks to be. You could try changing the rudder control used, from Rudder Set to Axis Rudder Set (which you use with the DC-6 profile, although you only seem to have a DC-3 in that profile). Also take a look to see if there are any Input Events or Lvars that look like they may controller the rudder (using Log->List Input Events and Add-ons->WASM->List Lvars)

The usual cause of such behavior is dual assignments, i.e. having the rudder assigned to two different axis. Can you do the following please: once MSFS and FSUIPC7 have started, activate logging for Buttons & Keys, Events and Axes Controls. Load your aircraft, then move the rudder to full left, then full right, then back to center. Then exit FSUIPC7, and show me / attach your FSUIPC7.log and FSUIPC7.ini files and I will take a look. John

Did you read that Appendix? For a slave/client PC, you do not need MSFS installed and you do NOT install FSUIPC via the installer - you copy it across. Please read that appendix. If you have installed MSFS on your client PC then you need to run it at least once before running the FSUIPC installer. If it does not install, what does it say? Have you checked the InstallFSUIPC7.log file? Check that for any issues, and you can also post/attach it here. John

FSUIPC will do nothing with such sections (i.e. they will be ignored). FSUIPC only uses certain section names - others will be ignored. However, there position in the ini file may change when other sections are re-written, but I am not sure about this - just try it. John

Isn't this the same behavior you see when you push the button in the VC?

This is because you are using offset 0x2FA8, which is HSI BEARING, which, as pointed out earlier, holds: You should try with offset 0x0580 (PLANE HEADING DEGREES TRUE) or 0x2B00 (PLANE HEADING DEGREES GYRO). If you want to use PLANE HEADING DEGREES MAGNETIC, you would need to add this to an offset. Note also that for some offsets, you will need to convert the offset value to degrees before applying (e.g. for 0x0580 you have to *360/(65536*65536) to convert to degrees). Or just use a preset or calc code - easier!