John Dowson

No - it will still scan for lvars on an aircraft change. Setting this parameter to 0 will mean that only one scan for lvars will be performed, and after LvarScanDelay seconds after the aircraft is loaded. So, any lvars created after this scan is performed will not be visible to FSUIPC7 for the lvar functionality, although you can still update such lvars via presets/calculator code. It takes place LvarScanDelay seconds after the aircraft is loaded, i.e. after you press the Ready To Fly button and the camera changes to cockpit. The LvarScanDelay parameter takes effect after the camera changes to cockpit, do this is probably after the aircraft has fully loaded. You can check all lvars are loaded by performing a manual scan for lvars, using the Add-ons->WASM->Reload menu option. If this discovers more lvars, you may want to consider increasing the LvarScanDelay ini parameter. Note that some aircraft and utilities seem to continually create lvars. However, it is debatable if such lvars are needed to be known anyway, so they can probably be ignored. And you can always use them via presets/calculator code. John

It wasn't, but this is not needed if FSUIPC7 is installed correctly. I have sent you a FSUIPC7.key file - please save this to your FSUIPC7 installation folder and then run FSUIPC7 to check that it is running as a registered version. Then re-run the FSUIPC7 installer. Your registration details will be pre-populated from the key file - try validating them. Do they validate? If so, what was your previous issue? If not, then it must be due to your VC++ redistibutables - are you sure that you updated them correctly?

You should not delete this one as that is the original that is copied to the paths given in the post. Then that would indicate it is an issue with P3D and not FSUIPC. Try re-installing the P3D client. And try starting with a default aircraft before switching to the PMDG 737.

It is the people who have an use an aircraft that create the presets, and MobiFlight host this community-driven effort to discover presets via the HubHob site (https://hubhop.mobiflight.com/presets/). You can also use the MSFS2020 channel on MobiFlight's discord server to ask and discuss about presets. I can also help with presets for aircraft that I have own or have access to, but I don't have the B727 so cannot help with this aircraft. Forget about lua for the time being - you shouldn't need lua as you should be able to implement most things via presets. Presets can also be used to control/set lvars and hvars. To determine what controls a switchm toy can use FSUIPC's logging facilities. Logging of Events and Axes Controls should reveal any standard FS controls used, and toy can use logging/listing of Input Events and lvars to see changes for these. You can also use the MSFS behavior debugging facilities to inspect the code that is used to control a button/switch - see https://www.badcasserole.com/uncovering-input-events-using-the-msfs2020-model-behavior-dialog/. I will see if I can get gold of the B727 and if so will take a look at the fuel cut-off switches to get you started.

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