John Dowson

Did you check that was the case? i.e. does that offset hold the correct value? If so, you could have a lua script (auto-ran) that monitors that offset (using event.offset) and when the value hits 16383 (or maybe below this) you could write a value of 1 to a different/spare FSUIPC offset and use that in the PM sound config. Of course, you would also need to reset that offset when the value in 0x0BD0 goes back below 16383 (or the value that you use).

Ah, sorry - then no, you cannot use that offset. Try logging offset 0x0BD0 and see what that holds when the spoilers are deployed: John

Ok, no problem.

Take a look at the PMDG-specific offsets - maybe this one: ? John

Also set WAPI Debug level logging (Log->WAPI->Debug) and use the following ini: FSUIPC7.ini

That is very strange...Nothing should happen when G18 is pressed on its own. Could you please activate logging for Buttons & Keys, and show me/attach an FSUIPC7.log file showing those issues, and also attach your current FSUIPC7.ini file. John

Ok. But be aware that is assigned in your general profile to start the ipcReady.lua: Not sure why you would want an assignment to start/restart that, as it is started by default once an aircraft is loaded. I will remove that. Please try the attached and let me know how it goes. When you hold button G18, the inc/dec should be 10x faster. John FSUIPC7.ini

On the same controller? If not, which controller? How many button box interfaces do you have? Your ini shows 4 detected: but you also have assignments to another one that is no longer detected: You have several assignments to this that will not be working: Looks like that device is now the K device (Button Box Interface BBI-64) as you have re-assigned some of those buttons to that. In the attached ini, I have removed those assignments to the missing device that were re-assigned, and updated the remainder to use the K device. I have also added assignments to send the CRS inc/dec on a button release to see if this improves things. If you let me know which device has button 18 that you want to use for fast inc/dec then I can add that for you. Note also that you have several assignments to PMDG 737 presets in your general profile. These should really be in your PMDG profile - shall I move these across for you as well? John FSUIPC7.ini

Ok, thanks, If using the Fenix, it could be the FenixBootsrapper - issues with simconnect connections when using this aircraft have been reported before - see If there is anything in your EXE.xml for the fenix, try moving that to after the FSUIPC7 entry, although I doubt this will help as FSUIPC does not try to get a connection until .the DetectToConnectDelayAuto has passed, which is set to 60 seconds. If there is an entry for the FenixBootstrapper in the EXE.xml, you could try setting the Disabled property to True (temporarily) to see if that helps. You could also try removing the Fenix from your WASM folder (temporarily) to see if that fixes the issue. But its the SimConnect.log file that will tell you which add-on is misbehaving. John

First, please use the FSUIPC7 sub-forum for all issues/questions on FSUIPC7, not the main forum. I have moved your post. Which version of MSFS - 2020 or 2024? Or do you get this issue with both? I have checked with both versions here and do not see any issues, so it is something specific to your system. If FSUIPC cannot connect to MSFS, this is usually because there are no SimConnect connections available. This can only happen if something else has taken / used all the available connections. Are you running any other 3rd-party/simconnect applications? Do you have the Fenix aircraft installed? The first thing to do is to reboot and try again. If you get the same issue check your EXE.xml (location is in the InstallFSUIPC7.log if you do not know where this is) and see if any other applications are being started. If so, try re-ordering them so FSUIPC7 is started first. If this is due to another simconnect application using up all available connections, then you need to determine what application this is. To do this, you can enable SimConnect logging - see the following article on how to do this: The log file will show each connection, and should tell you if one or more of your clients is behaving badly and taking up all the connections - there are several known clients that have done this over the years (e.g. Fenix bootstrapper). If you have not done so already, it is also a good idea to increase the number of SimConnect clients allowed, by setting the MaxClients parameter to 128 (default is 64) in your SimConnect.xml file (whose location is the same as for the SimConnect.ini file described in that post I referenced above). John

Its not that difficult.... First, do your rotaries have 1 or two buttons on each direction? You can check this in the FSUIPC button assignments window - do you see different buttons registered if you turn fast and slow, or just the one button regardless of speed (try a few times)? If just one button, do you want to use a different button or key press to switch between slow and fast selection? And do your rotary buttons emit just presses, or alternate press and releases? If you show me your assignments (FSUIPC7.ini file), I can help you set this up. John

I have just looked into this further. I have rotaries with two buttons in each direction, for fast and slow, and the rotary alternates between sending button press and release events. If I assign both the fast and slow inc/clockwise buttons to the preset PMDG_B737_MCP_FO_CRS_INC on both press and release (with a similar assignment for the dec), then I can get single increments when turning slowly, and large increments (>100) if I turn fast. No need to overload the assignments to send multiple controls. Not sure what these offsets hold, but it is not the actual course set, so this cannot be used.

Yes. If you use ipc.createLvar, FSUIPC knows that a new lvar is created and will rescan/reload all lvars so that the one created is available/known to FSUIPC. This also applies if you create an lvar via FSUIPC offsets. If you create an lvar in an ad-hoc manner by executing some calculator code, then FSUIPC does not know that a new lvar has been created and so this lvar will not be known to FSUIPC until a WASM reload/rescan is performed. There is a known issue, in both MSFS2020 and MSFS2024, in that the FSUIPC WASM module can crash when scanning for lvars - see Previously the FSUIPC WASM would occasionally re-scan for new lvars and push these out to FSUIPC (as well as any other clients) when found. However, this facility was disabled quite some time ago due to this causing a WASM crash. Yes, that is as expected due to the reason given earlier. John

There are various methods to have fast & slow inc/dec on a rotary button, and this depends on the rotary and what button events it sends out. Some rotaries have two buttons in each direction, one triggered on a slow move and another on a fast move. For such rotaries, you can assign the slow buttons to the small inc/dec and the fast buttons to the larger inc/dec controls. For rotaries that have only one button in each direction, you can either: 1. Use a lua script to convert the single button press/release to two virtual buttons, one for fast and another for slow, and then assign to the virtual buttons. There is an example script provided that does this (will need configuring for your system), called Rotaries.lua. 2. You can overload the buttons to have both fast and slow in/decs, and then use a compound condition on the assignment so that only one of these is fired depending upon the state of another button or offset. You could also do this on the state of a key press, but to do this the keypress would set an FSUIPC offset and then the inc/dec assignment would use a compound condition on this offset, and the key release would then clear the offset. Note also that some rotaries alternate between sending out button presses and button releases. For such rotaries, you need to assign to both the press and release. You also need to determine what to send for the fast increment/decrements. FSUIPC does provide some fast controls (e.g. Heading Bug Inc Fast, Heading Bug Dec Fast), but I doubt these work with PMDG. The simplest thing to do would be to send the same control that you use for the slow inc/dec, but send it multiple times (e.g. duplicate the fast assignment line 10 times, changing the index number for the assignment so that it is unique, to send the control 10x). Alternatively, you could have a lua script that read the current left/right course value, applies whatever delta you need to that, and then send that. The current course headings are held in the PMDG-specific offset 0x6520: and the following PMDG custom controls allow you to set the course directly: John

You cannot read the value of an lvar directly like that, as it only exists in the simulator, not in FSUIPC or the lua thread. To read an lvar value, use the ipc.readLvar function, e.g if ipc.readLvar("L:VC_Dome_Light_Display_VAL") == 0 then ipc.execCalcCode("39 (>L:VC_Miscellaneous_trigger_VAL,number)") end You could also define a preset with the following calc code: (L:VC_Dome_Light_Display_VAL, number) == 0 if{ 39 (>L:VC_Miscellaneous_trigger_VAL,number)} then assign to that preset - no lua needed (more efficient!). John

Try the preset TCAS SWITCH POSITION TA RA: John

Why not just use the provided preset Autbrake Off? That uses the following calculator code: 10 (>L:VC_Autobrake_SW_VAL) If you really want to do this via lua, then a simple script just containing ipc.execCalcCode("10 (>L:VC_Autobrake_SW_VAL)") should do the trick. I see you just replied... Yes, thats fine. But there are presets available for this - the following presets are available for the Autobrake: There are two presets for 'autobrake off', but if you look at the descriptions the first is incorrect and switches to max, and the 2nd one is the correct one. I don't know or understand why they did not just correct the first one rather than leaving it and adding another preset. This 2nd preset was also added after the current release of FSUPC7, and so is not available in the current version. In fact, as there is also other presets with the same name, it won't be loaded as preset names must be unique in FSUIPC. Therefore, I would advise that the best way to do this would be to define your own preset in the myevents.txt file: //iFly/737-Max8/Gear IFLY_737Max_Autobrake_Off#10 (>L:VC_Autobrake_SW_VAL) Then assign to that preset. John

Did you try the presets? As I said, if they are not working, you can ask about this on the MobiFligh support on Discord. How does that variable change when you start it manually? Do you also see any events or input events when starting it manually? It could be that something else is needed. You can also try inspecting the switch behavior to see how it works - see https://www.badcasserole.com/uncovering-input-events-using-the-msfs2020-model-behavior-dialog/

👍

I have done some further testing on writing to offsets 0x3110 (for control number) an4 0x3114 for the parameter, and this works as expected, i.e. the control is always sent when writing to offset 0x3110, even if its the same control number, and if the parameter in 0x3114 has been changed or not - whatever that offset holds when 0x3110 is triggered will be used. This is the case in the current released version, so that patched version I attached is not actually needed. So if you are seeing different behavior when writing to these offsets via SIOC, then it is an issue with SIOC. John

Sorry, but I have no idea. Are you saying that you previously had it connected via a COM cable to COM ports, and are now using a serial-to-USB cable and it is connected to a USB port? Why are you configuring COM ports if it is a HID/USB connection? Why do you need to set a baud rate if it is connected via USB? Have you tried using the PFC hid driver rather than the com driver? I have no PFC equipment and have never even seen or used any. All my knowledge on this comes from the documentation and existing support requests, so I suggest you start there (i.e. read the documentation).

Btw, the calc code for FNX320_APU_START_SWITCH is: (L:S_OH_ELEC_APU_START) 2 + (>L:S_OH_ELEC_APU_START) i.e. it is incrementing the lvar by 2, not 1. So maybe try: - Toggle APU Start Button local val = ipc.readLvar("S_OH_ELEC_APU_START") if val == 0 then ipc.writeLvar("S_OH_ELEC_APU_START", 2) else ipc.writeLvar("S_OH_ELEC_APU_START", 0) end The calc code for the press/release presets looks rather strange to me, as it seems to be sending two values to the lvar, which I didn't think possible: push: 1 (L:S_OH_ELEC_APU_START) ++ (>L:S_OH_ELEC_APU_START) release: 0 (L:S_OH_ELEC_APU_START) ++ (>L:S_OH_ELEC_APU_START) If the presets are not working, you can ask about this on the MF support discord server (MSFS2020 channel). John

They are MF presets, and there is also FNX320_APU_START_SWITCH. You can assign to presets directly (check the select fir Preset checkbox), or in lua you can use ipc.execPreset function. I don't have the fenix to check these. John

Does the lvar change values? Ifthe script is sunning as expected and the lvar is changing values, then you need something more than just to set that lvar. Why not try the presets instead: APU Start Button Push and APU Start Button Release Use logging to see if the script is running and the lvar is being updated: set logging for Lua Plugins and WAPI debug level logging.

Your FSUPC6 installation is here: So all FSUIPC related files should be under that folder. However, you should NOT use the P3D installation folder. If yuo have installed there, then uninstall and re-install in a different (non windows-protected) folder. Don't foget to copy/move your FSUIPC6.ini and FSUIPC6.key files across to the new location to preserve your settings and registration, as well as any other files (*.lua, *.dll) that you are using. Are the button assignments working? If the ini file you attached is the one being read, I cannot see how just the axis assignments are lost. Can you set logging for Axes Controls and show me another log file, if you get the same issue after re-installation. Note that you should also always exit P3D/FSUIPC before attaching log files - the one you attached shows that FSUIPC was still running. Are you sure that this is not because the system is paused? There are a few messages indicating that the sim pause is turned on, but non indicating that it was turned off: Note that you also have controllers turned on in P3D: when assigning in FSUIPC, best to turn off controllers in P3D. If controllers are on, make sure that any axes/button that is assigned in FSUIPC is not assigne in P3D. And be-aware that sometimes P3D can automatically re-assign a button or axis, so you may need to check regulary if you get issues. John