These are the Support Forums for FSUIPC and related products.
These forums replace the old support forums which have been running for 20+ years. The old forums contain a wealth of information on all FSUIPC products, but are now no longer available.
Please note that you will need to Register and Login to post for support, and also to download attachments. You can view these forums without registering.
Support is also available via Discord. Please use the following invite link to join the FSUIPC Discord server:
https://discord.gg/zjwUTrxmmE
FSUIPC7 log around an uncommanded dual engine shutdown (Fenix A320, MSFS 2024) - help reading it?
Hi John,
I'm chasing uncommanded dual engine shutdowns in MSFS 2024 that I've seen in the Fenix A320 and the Aerosoft A346 Pro. Because I had event, axis and button/key logging switched on, FSUIPC7 recorded the moment it happened. I have no buttons, keys or axes assigned in FSUIPC. The only script is the Lua callout script PMCO_FNX32X, started via [Auto]; I checked it and it contains no ipc.control, writeLvar or other write calls, it only reads values. I would appreciate your view on the log, as you can read it far better than I can.
Setup: FSUIPC7 7.5.8, MSFS 2024 1.8.16.0 (MS Store), Fenix A320, WinWing URSA MINOR 32 Throttle Metal R and Joystick L with SimAppPro2 0.1.10 (Fenix support active), ChasePlane, VR with Meta Quest 3 via Virtual Desktop.
What happened (4 Oct 2026, local time CEST):
- 17:08:24 a number field in ChasePlane's camera window got the cursor; MSFS blocked the sim inputs. I typed a value (your log shows Backspace, 0, ., 1 and arrow keys).
- 17:08:50 the field lost focus and MSFS released the input block. In the same second the Fenix log shows "Engine control 1: Master switch off", and at 17:08:52 both engines cut off. Parallel 42 checked their logs and confirmed that ChasePlane sends no aircraft command at that point.
What I see in the FSUIPC log (excerpt attached, unmodified lines, time base explained at the top):
1. No button or key event at all around 17:08:50.
2. 17:08:50.5 to 17:08:51.0: LIGHT_POTENTIOMETER_SET 32/33/34 to 0 and LIGHT_POTENTIOMETER_13_SET going 7, 2, 0, all logged as AXIS.
3. 17:08:52.2: TOGGLE_FUEL_VALVE_ENG1 and _ENG2, which I take to be Fenix shutting the engines down after the master switch change.
4. The same light potentiometer pattern (rising this time) appears at 15:07:08, exactly when the Fenix log also shows "Master switch off" (on the ground, engines off).
5. Throughout the session SPOILERS_ARM_SET, FUEL_SELECTOR_LEFT and FUEL_SELECTOR_2_RIGHT arrive about every 100 ms, and after the shutdown FUEL_SELECTOR_RIGHT takes over.
For comparison: on 6 October I repeated text-field focus/release tests (Microsoft EFB, Fenix EFB, ChasePlane) in 2D, on the ground with engines running, without typing. No shutdown occurred, and the light potentiometer pattern did not appear. The original incident was in VR, in flight, and involved typing beforehand.
My questions:
1. Can you tell from these logs whether FSUIPC or the running Lua script issued any engine, fuel or mixture control? Which possible input paths would not be visible in this logging?
2. Does "AXIS" for the LIGHT_POTENTIOMETER events mean they came from an input device, or can it also be a SimConnect client or WASM module sending them?
3. Is there a way to see which client sends the controls repeated every 100 ms?
4. Is there a logging option that would capture L:var writes (for example a WASM module writing the Fenix engine master variable), so I can see where the switch change comes from next time?
Related reports with videos:
- MSFS DevSupport: https://devsupport.flightsimulator.com/t/native-efb-bug-focus-input-field-unfocus-input-field-now-linked-to-full-engine-shutdown-rat-deployment-in-payware-aircraft/18572/3
- Aerosoft forum (A346 and Fenix): https://forum.aerosoft.com/index.php?/topic/185819-dual-engine-shutdown-in-flight-after-an-airport-search-in-the-efb-not-only-in-a340-also-fenix-a320/#comment-1138549
I'm not a programmer; I analysed this with AI assistance, but all observations are from my own flights.
Thanks a lot!
First, please understand that the event and axis control logging logs all these events happening in the FS, not what is being sent from FSUIPC.
Posted by: @micromoonCan you tell from these logs whether FSUIPC or the running Lua script issued any engine, fuel or mixture control?
No. However, it should be easy to determine what the lua script is doing by just looking at it - does it send any such controls? If so, you can set lua debug logging which will show/tell you what the script is doing.
Do you have any assignment in FSUIPC to any engine, fuel or mixture controls? If not, they cannot possibly be coming from FSUIPC.
Posted by: @micromoonWhich possible input paths would not be visible in this logging?
Event logging shows all events that are happening in the sim. You cannot tell the source of such events.
Posted by: @micromoonDoes "AXIS" for the LIGHT_POTENTIOMETER events mean they came from an input device, or can it also be a SimConnect client or WASM module sending them?
No, it just means that it is an axis control (i.e. Light Potentiomenter Set works on an axis range). This type of event is usually emitted by the aircraft itself. Many aircraft continually emit certain events - these can be considered as 'noise' as they just fill the log. They can be ignored using the DontLogThese ini parameter.
Posted by: @micromoon3. Is there a way to see which client sends the controls repeated every 100 ms?
No, but its most likely the aircraft itself.
You can activate logging for SimConnect if you like, which would show all SimConnect clients and their activity. However, such logs are extremely large and difficult to analyze, although there are some 3rd party utilities for this (which I mean to look into but still haven't tried).
Posted by: @micromoonIs there a logging option that would capture L:var writes (for example a WASM module writing the Fenix engine master variable), so I can see where the switch change comes from next time?
Yes, you can log lvar writes/updates with FSUIPC, to both the FSUIPC7.log file or to a separate window. See the section Logging Lvar Updates on page 48 of the Advanced User guide.
Why did you attached the logs 4 times - are they all the same? Took a look at one and it didn't show much of use, and no idea what the fenix log is.
The links you added were also removed, but I don't think FSUIPCs logging can help much with this issue. But can you show me a full log file - remove all logging accept logging for Buttons & Keys and Extras, and attach your (full) log file, your ini file and your lua script and I will take a look.
Hi John,
thanks a lot for the quick and clear answer.
Sorry about the duplicate attachments, that was an upload mistake on my side. They were the same files: an excerpt of my FSUIPC7.log and an excerpt of the Fenix aircraft's own system log (log-System.txt, written by the Fenix A320), which records the moment the engine master switch changed.
To your questions:
- I have no assignments in FSUIPC at all, so nothing to engine, fuel or mixture controls.
- The Lua script (PMCO_FNX32X, a callout script) only reads values. It contains no ipc.control, writeLvar or other write calls.
So I agree FSUIPC is very unlikely to be involved. Your hint about logging Lvar updates is exactly what I need. I have now set:
- LogEvents=No, LogAxes=No, LogButtonsKeys=Yes, LogExtras=Yes
- [LvarsLogged] with the 12 Fenix switch Lvars that matter here (S_ENG_MASTER_1/2, S_ENG_MODE, strobe, beacon, nav, BAT1/2, GEN1/2, two fuel pumps)
My next test session is planned for this evening. Afterwards I will attach the full FSUIPC7.log, my FSUIPC7.ini and the Lua script, as you asked. 👍
Posted by: @micromoonI have no assignments in FSUIPC at all, so nothing to engine, fuel or mixture controls.
Ok. But note that FSUIPC can still have an affect on axes controls if you have done any calibration in FSUIPC. Any calibration (in the general none=profile specific section) can affect all aircraft. This is why I would like to see your ini, so that I can check this.
Posted by: @micromoonMy next test session is planned for this evening. Afterwards I will attach the full FSUIPC7.log, my FSUIPC7.ini and the Lua script, as you asked. 👍
Ok. As you say, it is very unlikely that FSUIPC is involved / causing this issue, and a quick check of your files would confirm this.
Thanks, good point. I checked: my [JoystickCalibration] section only contains RudderBlendLowest=1, no calibrated axes, and there are no profile sections. I did´nt check out further and might give more information after next flight. 👍