John Dowson

I do not understand why you are posting. Do you actually have a question?

So what is the issue? That means you are good to go - click next or skip and finish the installation process and you are good to go. Any issues with installation and/or registration, please see the provided installation and registration guide. John

Very strange - never heard of that issue. Anyway, glad its now working. John

Yes - error 2 is not really an error and shows PACX was running and connected. Unfortunately you attached your log file for when you restarted and PACX connected ok. I need to see the log file from when FSUIPC7 is auto-started and PACX fails to connect. Please show me/attach that the next time it happens. If you restart FSUIPC7, then the previous log file will be renamed to FSUIPC7_prev.log. John

Why are you still using a trial license? The trial license is meant for you to try FSUIPC for a period of a few weeks or so. After that, if you don't want to purchase, you should either delete or use the unregistered version. Ok. That log file is useless. Also, when it next happens, can you also attach the FSUIPC_WASM.log file and any events you see related to FSUIPC. Also, please check the MSFS console for any messages relating to the FSUIPC WASM. Was the first flight/session a long one? i.e. how many hours (approx) and how many flights? What other add-ons are you using? Do you use GSX?

I am not familiar with the 787 - where is this button located? Is there even such a button? I have read this: With VNAV active, pushing the IAS/MACH selector enables speed intervention See https://www.avsim.com/forums/topic/640784-airspeed-intervention-unstable-approach/

Can you check in the Windows the Event Viewer please and see if there are any events related to FSUIPC (under Windows Logs -> Application) and if so save the event and show it to me/attach it. So this has happened in the past? Was this reported? The next time it occurs, can you please show me the log file from both when FSUIPC freezes, and also when you restart and it stops responding. Your ini file is pretty empty - looks like you are not using FSUIPC for anything except auto-save.... John

Not offhand. There is a preset for altitude intervention: AUTOPILOT_PUSH_ALTITUDE_INTERVENTION This uses the hvar H:AS01B_FMC_1_AP_ALT_INTERVENTION You could test to see if there is a similar hvar for the speed intervention. Try executing the calculator code (Add-ons->WASM->Execute Calculator Code) (>H:AS01B_FMC_1_AP_SPD_INTERVENTION) and maybe also try: (>H:AS01B_FMC_1_AP_SPEED_INTERVENTION) to see if any of those work. If so, you can define your own preset. Otherwise, you can try inspecting the behavior of the button using the MSFS development tools - see https://www.badcasserole.com/uncovering-input-events-using-the-msfs2020-model-behavior-dialog/ Also you can try logging Input Events (Log -> Input Events), press the Speed Intv button and see if anything is logged, and if so use that. I can take a deeper look at some point, but probably not for at least a few days. John

To be clear, for this you should check Select for Preset, and choose AS530 RightLargeKnob Left - either directly from drop-down menu (will take a second or two to populate) or via Select Preset.. button. John

This is not necessary. You do not need to install/use the MobiFlight WASM module if using FSUIPC7. Do you need to use MobiFlight? i.e. do you have any home-built equipment that requires its use? If not, you should remove this from your WASM community folder and try again. All you should need to do is download and install FSUIPC7. This contains a MobiFlight events.txt file - it is pretty recent and should not need to be updated, but you can update this if there are new MF events not in the current one. You should be able to assign to these events/presets and they should work via the FSUIPC WASM module. Ah, this is what you are doing wrong. You are assigning to the MF events, not the presets. If you assign directly to MF events, you will need to install/use the MF WASM module. However, it is FAR better and easier to use presets instead. To do this, Select for Preset, then click the Find Preset... button and locate the required preset and use this. The MF add-on event functionality (and the event file functionality in general) are an older method of control and should really no longer be needed, as everything is far easier using the presets, and the MF presets in particular. All add-on custom events will now have a preset equivalent that you should use instead. So, remove the MF WASM module from your community folder. Then change your assignments from using the MF events to using presets, and remove any *.evt files from your FSUIPC7 installation folder. Any issues, please attach your FSUIPC7.ini and FSUIPC7.log files and I will take a look. John

The files you are attaching don't make sense: From your prev.log file: From your (latest) .log file: From your ini file: Are they all from the same folder? They should be, but I do not understand how your log files can show a different version than your ini file. Please run MSFS again with FSUIPC7, then open your installation folder (File->Open Installation Folder...). That will be the location of your log and ini files that I need to see. And PLEASE at least check your files before posting them - if they are not from 7.4.12 or later, don't post them as they are useless to me. John

Looks like you are experiencing a WASM crash, the same as @EisernUnion. Can you please download and use the updated version of FSUIPC7 + WASM posted above and set the log level to Trace in the WASM, and re-attach your files the next time you get an issue. Your log files will be very large and will probably be to big to attach even when compressed. If so, try using one of the free file transfer services, e.g. FileTransfer.io John

I do not provide links to older versions - only the latest version is supported. Please show me/attach your FSUIPC7.log file (from 7.4.12, not 7.4.11). John

Can you also try manually starting FSUIPC7 to see if that makes a difference. Once FSUIPC7 is started (with MSFS), just exit, and restart FSUIPC7 once MSFS has arrived at the main menu. Does PACX then work? John

That is a typo - I will correct . You should always use the assignments panel to create your assignments, or at least your initial ones. You can then edit the ini to add offset conditions, etc, or to overload. I do not understand why on earth anyone would want to create an assignment entry by hand - I would never do this... They are not available as nobody has requested this to be added before. I normally don't add simvars any more, as it is quite straightforward for users to add any simvars to offsets, but i will add this one. It will be added to offset 0x0B22 (2-bytes). It has been added in the attached beta version (7.4.13a). John FSUIPC7.exe

No they are not - I need to see your FSUIPC7.log file, not your InstallFSUIPC7.log file.

It will be listed under the Add-ons menu. No. No idea. Please attach your InstallFSUIPC6.log file. John

Thats the GUID - see my previous comment. You don't have to make new assignments, a simple edit of the ini file would fix it. A new letter will be assigned to the new GUID, you just have to change that letter to the original (also on device name), and then delete the original lines using that letter. Try that the next time a GUID changes - or post your ini and I can adjust for you. John

First show me your FSUIPC7.log file, and also your FSUIPC7.ini and I will check those. How is PACX started? By FSUIPC7, MSFS or are you starting it manually? If you start or re-start it once FSUIPC7 is connected to MSFS and up and running, do you still get the error? And does PACX connect to FSUIPC7, MSFS or both? I will take a look at your files to see if I can see anything, but if other FSUIPC7 clients are connecting, it sounds like a PACX issue and you will need to contact their support. John

This is nothing to do with the 'device ignored' issue. If you lost key presses, this will be a timing issue. Please show me your FSUIPC7.log file and I can check the auto-start parameters. You shouldn't need to do this, unless you manually removed your initial assignments. Even when a device is not available, the assignments are still kept. If the assignments were lost and you didn't remove them, then this is probably because a new name or GUID was assigned to the device, and the fix for this is to manually edit the FSUIPC7.ini not re-add the assignments. Attach your FSUIPC7.ini, and I will check if the old assignments are still there and clean-up your ini file for you. John

Just send the logs when you get the WASM crash again.

@EisernUnion Can you use this version of FSUIPC7 going forward - this just has an additional log message to log when the WAPI is acquired, or why not: FSUIPC7.exe And here is an updated WASM with additional logging - you will need to set the log-level of the WASM (not the WAPI!) to Trace, as explained earlier: FSUIPC7_WASM.wasm (that is also a debug-enabled version, and may allow you to get more information about the crash from the MSFS console) layout.json manifest.json Please use those files to replace the ones in your Community FSUIPC WASM folder (fsuipc-lvar-module) (i.e. under your MSFS Community folder) - the *.wasm goes in the fsuipc-lvar-module\modules folder, the others directly under fsuipc-lvar-module. The log file will be very large with Trace logging enabled, especially when running for hours. It will need compressing/zipping before attaching. Send me your updated files again when you next get the WASM crash and I will take a look. I will also test further here. John

Yes, I need more information to track this down. Maybe you should enable TRACE logging in the WASM for now. I will also add some more logging information to the WASM and provide you with an updated module to try later today. John

The OPs issue was not with FSUIPC - he was using Axis and Ohs. His problem resolved when he switched to using FSUIPC. First, check that you have removed any throttle assignments in MSFS - I recommend using an empty profile for your controllers in MSFS if assigning in FSUIPC, but it is also possible to mix-and-match your assignments, i.e. have some in MSFS, some in FSUIPC. But you will get issues if you assign an axis (or button/switch) both in FSUIPC7 and in MSFS, or in any other software. Axes, as well as buttons, keys, switches, etc, should only ever be assigned in one place. Also check your MSFS assistance options -some of these can control the throttle for you. If none of that works, please show me/attach your FSUIPC7.log and FSUIPC7.ini files and I will take a look. No additional logging needed initially, but I may also need to see a log file with logging for Axes Controls activated at some point. That is a question for the OP - when a question is for a specific person, you should tag them so that they get notified. So hopefully @Adamski can respond to this question. John

It looks like the WASM crashed at 21:54:21. I have no idea why, and I will need to be able to reproduce this to fix this issue. These errors are strange: These are probably due to a timing issue. Could you please activate WAPI debug logging (Log->WAPI->Debug) and keep that active for now. As you are also getting a lot of lvar/hvar reloads after initial; connection., could you change the WASM LvarScanDelay parameter: LvarScanDelay=10 Best to change/set this in your FSUIPC_WASM.ini file in your persistent storage area (i.e, under your AppData folder and not on the WASM Community folder). See the Advanced User guide for details on this if needed. So it looks like your issue is with the WASM crashing, and this only happens later during a flight, e.g. in one log it was over an hour after starting, and in the other over 4 hours after starting. This is a memory reference error (C000005). This is very strange and I will look into this. John