John Dowson

And does it show rhat the WASM terminated correctly or had crashed (when you get the issue)? You are not reading the manual correctly - this is what it says: i.e. the FSUIPC_WASM.log file can be found in the WASM persistent storage area and not under your Community folder. John

First, you posted in the wrong sub-forum for FSUIPC5/6 support - I have moved your post. The usual reason for such a crash is a corrupt weather file - please see the following FAQ entry: If that is not your issue, please show me / attach your FSUIPC .log file. Also. please check the windows Event viewer for a crash report and show me the details.

If it is only assignments to lvars (or presets) that stop working, it could be due to a WASM crash. Have you tried exiting FSUIPC7 and restarting it? If not, please try that the next time this occurs. If it still fails and FSUIPC7 fails to load the lvars, then the WASM has probably crashed. To verify this, you need to exit MSFS and check the FSUIPC_WASM.log file - if the last line does not show that the WASM exited properly with the following message logged: then the WASM module has crashed. It has been reported that this occurs only when using complex aircraft AND complex scenery, and is more likely to happen after an aircraft change. The crash seems to be an MSFS issue that I will report. If you find that the WASM is crashing then you can try tuning the WASM via ini parameters to prevent this. You need to disable continual lvar scans by setting LvarScanFrequency=0 and if setting this it is also a good idea to tune the delay of the initial scan, by increasing the value of the LvarScanDelay ini parameter (the default is 5 seconds). Suggest, for complex aircraft, you use: LvarScanDelay=10 Please see the Advanced User guide on setting WASM ini parameters. You should set these in the FSUIPC_WASM.ini file in your WASM persistence area, not the one in your Community folder. If this doesn't yet exist, copy the one from your Community folder to the WASM persistence are location (details in the Advanced User guide) and then edit/modify. If the WASM isn't crashing, then something else is stopping the lvars from being updated. Please enable WAPI Debug level logging (Log->WAPI->Debug) and Event logging, as well as WASM Debug level logging (via the FSUIPC_WASM.ini file) and the next time this occurs please exit MSFS and show me/attach both the FSUIPC7.log and FSUIPC_WASM.log files.

You can do this by having the logging console window open (Log -> Open Console) and then press the button in the VC and see what event(s) is/are logged. If you see events logged when you are not doing anything, then these are most probably events continually triggered by the aircraft. Best to ignore such events by setting the DontLogThese ini parameter (see Advanced User guide for details). I don't know (and don't know what "SAS" is!) and as I don't have this I cannot advise. Use logging to see id any events are logged. Also try listing input events and lvars to see if any of those look applicable. As a last resort, you can also inspect the behavior of the switch using MSFS's behavior debugging facilities - see https://www.badcasserole.com/uncovering-input-events-using-the-msfs2020-model-behavior-dialog/ for details on how to do this. John

Your log file indicates that there is a problem with the WASM - FSUIPC establishes a connection to the WASM but no lvars are received. This could indicate a possible crash in the WASM. To verify this, you need to exit MSFS and check the FSUIPC_WASM.log file - if the last line does not show that the WASM exited properly with the following message logged: then the WASM module has crashed. It has been reported that this occurs only when using complex aircraft AND complex scenery, and is more likely to happen after an aircraft change. The crash seems to be an MSFS issue that I will report. If you find that the WASM is crashing then you can try tuning the WASM via ini parameters to prevent this. You need to disable continual lvar scans by setting LvarScanFrequency=0 and if setting this it is also a good idea to tune the delay of the initial scan, by increasing the value of the LvarScanDelay ini parameter (the default is 5 seconds). Suggest, for complex aircraft, you use: LvarScanDelay=10 Please see the Advanced User guide on setting WASM ini parameters. You should set these in the FSUIPC_WASM.ini file in your WASM persistence area, not the one in your Community folder. If this doesn't yet exist, copy the one from your Community folder to the WASM persistence are location (details in the Advanced User guide) and then edit/modify. If the WASM isn't crashing, then something else is preventing lvar reception. Please enable WAPI Debug level logging (Log->WAPI->Debug) as well as WASM Debug level logging (via the FSUIPC_WASM.ini file) and the next time this occurs please exit MSFS and show me/attach both the FSUIPC7.log and FSUIPC_WASM.log files. John

I don't think this is possible. I am not sure what yoke you are using, but the PFC documentation states:

This sounds very strange - I have not heard of such behavior before. Does this happen with all aircraft or just with specific aircraft? You can show me / attach your FSUIPC7.log and FSUIPC7.ini files and I can take a look to see if I can see anything, although I am not sure what I am looking for. You can also try with logging for Axes Controls activated and open the logging console (Log -> Open Console). This will show you the axes controls that FSUIPC7 is seeing- try moving the ailerons smoothly through there full range and see what values are logged.

You can leave them unchecked. You only need to enable logging when tracking down an issue. John

Yes - not sure where that came from 😉!

Please let me know your order number and I will check your details here. It does not show in the devmode toolbar. Please read the User manual. When FSUIPC7 starts, you should see a splash screen and it will then sit in your system tray. You can use the default hot-key Alt+F to open the FSUIPC7 main window. If you have any installation issues, please show me / attach your InstallFSUIPC7.log file. John

Can you please attach an FSUIPC7.log file showing your issue, i.e. with logging for Axes Controls activated and you move the throttles. The log file you attached doesn't event tell me what aircraft you are using...and ALWAYS exit FSUIPC7 before attaching files please. Try removing the calibration for throttles 1 & 2 as well - these are still calibrated, from your ini file: Some aircraft do not like post calibration (i.e. calibrating when assigning using Send to FS as normal axis). If you still have issues after removing the calibration, I will look into this next week - once you have attached an log file that is useful.

Many FS controls work when assigned internally but not when assigned externally - this has been reported to Asobo (a very long time ago...). You need to determine what works for the aircraft you are using. for example, for the Asobo King Air, there are presets: KA Fuel Left Condition Lever Low Idle KA Fuel Right Condition Lever Low Idle However, I do not see anything similar for the Black Square King Air. You will need to investigate to determine how this can be assigned. As I don't have this aircraft, i cannot really advise, but you should start by looking at any available Input Events and lvars. You can use FSUIPC's logging facilities to investigate these. You can also ask on the MobiFlght discord server (msfs2020 channel) if anyone can define a preset for you for this - that is the home of the community-driven effort to discover and publish presets for MSFS2020.

Please do not use the version attached above - that is now an old version (I will remove it). Please download and install the latest release, 7.4.16. If you still have issues with keys/hot-keys, see

Maybe ask your mate for further details on this control: what is he using to assign to this, and can he show the code for this assignment (or for that event)? Also, try listing the Input Events and lvars to see if any of those look like they apply to the spoiler lever/position.

I have just created a FAQ entry for assigning an axis to an lvar - see That is NOT a standard FS control/event. It may be a custom event, or possibly an Input Event or lvar. You can list the lvars and Input Events to see if it exists there, Does the aircraft come with an SDK, or with any documentation on custom events? If so, please check that. Also, do you know the range of values that this takes? You can use custom events/controls in several ways with FSUIPC7: - using a <custom control> number - by defining a preset - by using an event file (*.evt). For this, you would need to know what the event prefix group is John

There are several ways to assign an axis to an lvar in FSUIPC7, but the easiest way is to use a preset. First, you need to know: 1. The name of the lvar that you want to control. You can list the lvars using Add-ons->WASM->List Lvars to see the available lvars. 2. The value range of your axis. Most axes will gave the range -16384 to +16384, however some potentiometer axes may have a different range (e.g. 0-100). To verify the axis range, you can look at the IN value in the axis assignment panel when you move the axis. 3. The value range that the lvar takes. To determine this, you can list the lvars to see the values. Move the axis you want to control in the Virtual Cockpit to one extreme, then list the lvars (Add-ons->WASM->List Lvars). Then move the axis to the other extreme and list again. This will give you the maximum and minimum values for the lvar. Once you have to determined these three things, you can define your own preset in the myevents.txt file, located in your FSUIPC7 installation folder. Note that this file will not exist by default - you need to create this file. The format of a preset definition is <preset name>#<calculator code> where <preset name> is the name of the preset, the name that you will see in the assignment drop-down menus in FSUIPC <calculator code> is the calculator code that is sent to MSFS when you trigger the preset. The calculator code to set an lvar is as follows: <value>(>L:<lvarName>, Number) As the value will be coming from an axis, you should use a placeholder - either the @ symbol or the string $Param. You will also need to convert the axis value to the lvar value range. You do this using RPN (Reverse Polish Notation) calculations in the preset. As an example, lets define a preset for the A2A Comanche carb heat switch. The details for this are: 1. Lvar name is Eng1_CarbHeatSwitch 2. My axis range is -16384 to +16384. 3. The lvar range is 0 to 100 A preset for this would be: //A2A SIM/Comanche 250/Engine MY_PA24_250_Carbheat_Axis#$Param 16384 + 327.68 / 0 max 100 min (>L:Eng1_CarbHeatSwitch, Number) Breaking this down: - the first line, starting '//', is not just a comment, but is used to position the preset in the appropriate node in the tree view that you see when you click the Find Preset... button. This preset will be listed under Personal -> A2A SIM -> Comanche 250 -> Engine - the preset name (in the drop-down menus) will be My Pa24 250 Carbheat Axis - the input axis value ($Param) will be calibrated by 1. first adding 16384 to produce a value between 0 and 32768: $Param 16384 + 2. the result will then be divided by 327.68 to give a value between 0 and 100: 327.68 / 3. the result will be constrained to a minimum of 0 (0 max) and a maximum of 100 (100 min) 4. the resulting value will be used to set the lvar Eng1_CarbHeatSwitch Another example is for the ATR condition lever: 1. Lvar name is MSATR_CONDITION1_POS 2. My axis range is -16384 to +16384 3. The lvar range is 0 - 3 (i.e. 4 discrete positions) A preset for this would be: //Microsoft/ATR 42-600, ATR 72-600/Fuel MSATR CONDITION1 LEVER SET#$Param 16384 + 10923 / near 0 max 3 min (>L:MSATR_CONDITION1_POS) Once you have defined your preset, you can assign your axis to use the preset by selecting to assign using Send Preset to FS on the left hand side of the axes assignment panel. Note also that presets are only loaded automatically when FSUIPC7 initializes. If you modify the myevents.txt file while FSUIPC7 is running, you can use the menu option File -> Reload Presets to reload the preset files. For further information on using presets in FSUIPC7, please see the WASM section in the Advanced User guide. For further details on RPN and calculator code, please see https://docs.flightsimulator.com/flighting/html/Additional_Information/Reverse_Polish_Notation.htm

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,