John Dowson

It is no bother to me and I am not frustrated. However, I am always trying to reduce the time I am spending on support so that I can spend more time on other things, such as improving the functionality and documentation. If I continually have to answer or explain things further then the documentation is obviously not good enough and needs to be updated, otherwise I repeatedly get asked the same questions which is not only wastes my time but also that of my customers. I therefore like to clarify/update documentation (including FAQ entries) so that I can reduce such queries. I am therefore asking why it was not clear to you that you needed to set that ini parameter from the FAQ entry so that I can update it...

Your WASM log file shows this: If you have read the FAQ entry, it says to set LvarScanFrequency=0 Have you tried this? And can you tell me why the FAQ entry isn't c;lear on what to do about this...the FAQ entries are there so I don't have to explain this to every support request. If you can let me know why the FAQ entry for this isn't sufficient I can update it.... John

Did you not read my previous comment? Your WASM is crashing - please read the FAQ entry for this and follow those instructions.

@xkoote Did you manage to get this working yet using FSUIPC7? Also, do you know how to assign for the fuel cut-off levers in the B727?

@David123 Did you try the above or did you manage to sort out your issue, and if so, what was the problem?

Your upload limit will increase the more you post. If files are too large to attach, even when compressed, you can use a (free) file exchange service such as https://filetransfer.io/.

Can you please ALWAYS attach your full log rather than posting extracts. There is other information I need to see from this, such as which aircraft you are using. Depends... so you have anything assigned to those controls? Try activating logging for Buttons & Keys as this will tell you if those are coming from an FSUIPC7 assignment or not. Do you also have assignments in MSFS, or have you created empty profiles in MSFS for your controllers (recommended)? Many aircraft continually send certain events/controls, and these vary by aircraft. You can ignore such events by using the DontLogThese ini parameter. However, such events logged should not cause any issues - they are just noise in the log. Can you please check to see if you are experiencing a WASM CTD - see the following post If the WASM is crashing, follow the instructions there. If it is not crashing, follow the logging instructions in that post and attach your FSUIPC7.log and FSUIPC_WASM.log files here and I will take a look. John

An issue has been identified that can cause the FSUIPC7 WASM module to crash. When this occurs: - presets will no longer work - lvars will not be updated - FSUIPC can hang when restarted 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. If you experience any of these systems, please confirm that the WASM has indeed crashed. To do this, firs exit MSFS. Then open your FSUIPC_WASM.log file, located in your WASM persistence area which is: The last line in this file should be an 'END OF PROGRAM' line like the following: If you do not see that, then the WASM has crashed. The crash seems to be an MSFS issue that has been reported. 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 causing your issue. 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 MSFSm create a support topic and show me/attach both the FSUIPC7.log and FSUIPC_WASM.log files. John

When you run FSUIPC7 (or when it is auto-started), a splash-screen is displayed for a few seconds, and then FSUIPC7 will sit iconised in your system tray. To open the main window, either use the system trat icon or the default hot-key Alt+F. As you are NOT familiar with FSUIPC7, please read the user manual.... You do not need Steam installed. FSUIPC7 works with MSFS, and this can be a Steam version, and MS Store version or boxed. You can check your InstallFSUIPC7.log file to see what version was detected. No - you don't need WideFS (WideServer + WideClient) installed or refistered. WideClient is for use on a client/slave PC.

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.