John Dowson

First, you posted in the main support forum - please use the FSUIPC7 sub-forum for all issues/questions on using FSUIPC7 with MSFS2020/MSFS2024. I have moved your post. Looking at your log file, this is because the WASM module is not installed: Presets, lvars. hvars and calculator code will not work without the WASM. So please re-install and make sure the WASM is installed. If there are issues instaling the WASM, please show me / attach your InstallFSUIPC7.log file. Your log file also showa connection issue with quite a few connection attempts. You manually started FSUIPC7 before starting MSFS. If manually starting FSUIPC7, then it is always better to do this after FSUIPC has started. If you wnt to start FSUIPC7 before MSFS, then you need to set the ini parameter DetectToConnectDelay to the same value as DetectToConnectDelayAuto to prevent too many connection attempts once MSFS has started. It is generally better to use the auto-start facility, but if starting FSUIPC7 manually then do this once MSFS has started and arrived at the main menu (or adjust that parameter appropriately). John

Ok, let me know how it goes or if you have any issues/further questions. Thinking about this, it won't be that straight forward, as you need to repeat sending the control while the button is held down, and stop sending them when the button is released. This can be tricky in lua. Off-hand, I can think of a couple of ways of doing this, but each may have issues and will need testing: 1. Use event.button and have the script auto-run (in the profile). The event.button handling function should loop forever sending the control. To stop the controls being sent, you need to assign the same button, but on release, to restart the lua script. This will then kill the existing script (and end the forever loop) and restart it ready for the next button press. The downside of this solution is that there may be a small delay after releasing before pressing will work again, as the script needs to be restarted (and recompiled first). 2. Again, have the script auto-ran (in the profile), but use event.flag instead, and assign the button press to LuaSet <luaScript> and the release to LuaClear <luaScript> (or maybe just both to LuaToggle), with the parameter for both being any flag number (0-255). In the event.flag handling function, you would either: - start an event.timer, which would call a handing function at regular intervals which sends the appropriate inc/dec control - cancel the existing timer using event.cancel. The downside of this solution maybe the speed/throughput, which will need testing. Note also you could either use one script for both in/dec, or have separate scripts. Let me know how it goes, I could maybe take a deeper look over the weekend (or next week) and see what works best, and provide you with a lua template script if needed. John

The log file you attached shows that FSUIPC could not connect to MSFS. Nothing is going to work if it cannot connect. Try tuning your start-up parameters (namely the DetectToConnectDelayAuto ini parameter which may need updating/increasing) - see the Asvanced User guide for details, or the following FAQ entry: But the ini file you attached shows you do not have any axes/levers assigned in the general section of FSUIPC - your [Axes] config section is empty. You only have 10 button assignments, to prop pitch, throttle and elevator trim. So the axes must be assigned in MSFS, so check there. You also have one profile defined for the 'FSS Embraer E170 American', but this is empty (i.e. no assignments).

That is interesting, as this means that what you wrote to the offset was actually applied, as the read values are populated from what is received from the FS, not what is written (there are separate memory addresses for read and write).. Strange this has no effect then. Do you see the (read) values change in that offset when you actually change the trim? Ok, let me know how it goes or if you have any issues/further questions. John

Setting the ButtonRepeat ini parameter will apply to all buttons, as you say. If you want to change for a single button, you could try using a lua script (using event.button) instead of a direct assignment. But if this is for trim, doesn't the standard method of setting up trim work? i.e. rather than sending more/repeated inc/dec controls, set the elevator trim percent via offset 0BC0? You can also use different inc/dec deltas to have a fast and a slow increase/decrease. This is the standard method of assigning to replicate a trim wheel. For example, these are the assignments I use on a rotary to control the trim (for most aircraft): There are also some more advanced lua solutions in this FAQ entry: John

No. It is generally better to assign with Send direct to FSUIPC calibration (and calibrating). Only use Send to FS as normal axis if sending to calibration causes issues or doesn't work, which can happen with some aircraft. Note that, by default, axes assigned using Send to FS as normal axis are still calibrated in FSUIPC (if a calibration section exists), but this is performed after the event has been received back from the FS (which is masked/blocked). John

What has this got to do with FSUIPC? You can control how FSUIPC sees/reacts to button presses/holds/releases, but FSUIPC cannot do anything with what any other application, including the FS, receives/reacts to these button events. FSUIPC only sees and reacts to button press/releases, it does not send them on to other applications (that is windows' job!). The ButtonRepeat ini parameter controls how FSUIPC reacts to a held button press, and specifies the time between the button press and the first repeat, and the time for subsequent repeats, AS SEEN by FSUIPC. Changing this effects the button handling in FSUIPC only, not how other applications see/react to the button press. Note that FSUIPC does have a 'hold' action on button presses: However, I am not exactly sure what this does - looks like it is used when assigning a button to send a key press and will then hold the assigned keypress until the button is released. So if that is what you are looking for, you could try that. Normally you would just use repeat (R), i.e. the assigned control is continually sent while the button is held down, and set by checking the 'Control to repeat while held' checkbox in the assignments panel. John

Yes. Hopefully that modified version I attached above will allow the same control yo be resent via 0x3110 - let me know if that works. And as I said, I can't really help with SIOC. However, I do see that you had similar issues sending presets via SIOC 3+years ago, which you reported in this thread: Understandable - and that is why I was using parameters > 0, and just setting back to 0 in the event handler rather than in the client after sending the proper parameter, as you seem to be doing when using SIOC. I have looked at this several times now and just don't understand why lua executes so much slower in FSUIPC7 compared to previous versions of FSUIPC. There has been no real change in the lua engine or how this runs in FSUIPC7 (threads, etc) compared to previous versions, just updates to the additional lua library functions. So I don't understand the performance difference in FSUIPC7. I will look at this again when time permits, but as well as not having the time/resources for this at moment, I am not sure even where to start... John

I don't get that many fast updates as I was using the same parameter for both the press and release. As these alternate, it makes more sense to use different values, so the offset is actually changing on each click. So if I change: to - clockwise slow press, assigned to Offset Byte Set (on 0xA030) with value 1 - clockwise slow release, assigned to Offset Byte Set (on 0xA030) with value 2 - clockwise fast press, assigned to Offset Byte Set (on 0xA030) with value 3 - clockwise fast release, assigned to Offset Byte Set (on 0xA030) with value 4 - anti-clockwise slow press, assigned to Offset Byte Set (on 0xA030) with value 5 - anti-clockwise slow release, assigned to Offset Byte Set (on 0xA030) with value 6 - anti-clockwise fast press, assigned to Offset Byte Set (on 0xA030) with value 7 - anti-clockwise fast release, assigned to Offset Byte Set (on 0xA030) with value 8 then I can get around 11 callbacks on the fast button per second: Not as fast as using flags, and only applicable if your rotary buttons alternate between a press and release, in which case you should use separate parameters/values for press and release so that the offset change is triggered. John

I have made a few tests here. Some observations: 1. my rotary buttons alternate between presses and releases, so I assign the same control to both the press and release 2. only offset changes will cause an event to be triggered, i.e. if you are writing the same value, no event gets triggered. Observation 2 is the killer here, and it means that you have to reset the value in the offset to pick up further changes. However, this is best done in the function that handles the offset event. This is the lua I am using for this test: And I assign my rotary buttons as follows: - clockwise slow, assigned to Offset Byte Set (on 0xA030) with value 1 - clockwise fast, assigned to Offset Byte Set (on 0xA030) with value 2 - anti-clockwise slow, assigned to Offset Byte Set (on 0xA030) with value 3 - anti-clockwise fast, assigned to Offset Byte Set (on 0xA030) with value 4 With these assignments, I can get up to 7 or 8 slow button changes per second: However, when turning the dial two fast, the events aren't triggered: What seems to be happening is that although the offset is being reset back to 0, it is getting updated back to the fast value again (2) too fast to trigger the event. This makes the fast rotary buttons almost impossible to use consistantly. But if I switch to using flags to trigger the change, using the following lua: and assign my rotary buttons to: - clockwise slow, assigned to LuaToggle <luaFileName> with parameter of 1 - clockwise fast, assigned to LuaToggle <luaFileName> with parameter of 2 - anti-clockwise slow, assigned to LuaToggle <luaFileName> with parameter of 3 - anti-clockwise fast, assigned to LuaToggle <luaFileName> with parameter of 4 then I get a lot better throughput with both the slow and fast buttons - here you can see 23 change events logged in under a second: So maybe try switching to assign your buttons to a lua flag toggle (in SIOC, if this is possible...), and use event.flag in your lua scripts to pick up the button press (there are 255 flags available per script). Yes, this is a problem when using offset 0x3110, as only changes to the value in the offset trigger the event, so if you are writing the same control (i.e. Rotor Brake control number 66587) then only the first one will be sent and the subsequent ones ignored as there is no change in value in 0x3110. I will look into this in more detail when I have time, but can you try the attached version where I have reset the (internal) contents of 0x3110 once the event has been sent. Hopefully this will work but I don't have time to test this at the moment. Let me know if this works better when sending the same control.. John FSUIPC7.exe

That is not an issue - that is just a lua file that is ran on start-up if found. If its not found, a message is logged but this is not a problem. Have you configured GPSOut in FSUIPC6 (you didn't attach your FSUIPC6.ini file)? As far as I am aware, SkyDemon just needs the GPSOut data which needs to be configured via virtual COM ports.. Maybe check the following post (and the posts it references): John

Ok, I thought that would be the issue - no need to look at your files. Ooh - sounds like a bit of a pain. How did that happen? Did you check your Recycle Bin? John

Yes, but this can depend heavily on the system and configuration. There are various polling parameters that can be tuned, but you need to determine where the bottle-neck is first. And over-tuning can make things worse. But you probably won't get more than 5 or 6 clicks/button presses a second on rotaries when using lua (in MSFS2020/2024), Also, be aware that many rotaries have two buttons in each direction, one activated on a fast turn and another on a slow turn. There is also a lua script that can convert rotaries with a single button in each direction to work with 2 virtual buttons in each direction instead (see Rotaries.lua in the example lua scripts). What you would normally do is assign the fast rotary button to a large delta, and the slow button to a small delta, so the increments/decrements on a fast turn are a lot larger than a slow turn. You shouldn't need to do this (i.e. set the parameter to 0 first). And it is writing the control number that triggers the event being sent, so this should be written AFTER the parameter has been written. So, what is probably happening is that the previous parameter is being sent when you write the control number. Try writing the parameter first before the control number, and no need to reset to 0 or add a delay. But I think there is an issue with offset 0x3110 in that the control is not triggered if the value is not changed, so maybe this was added to get around this? With direct assignments to rotary buttons, I get a 15-35ms delay between each recognised button press. However, it will be a lot slower in lua. In the next few days I can write a short lua script that waits on an offset change, and assign the rotary buttons to set the offset, and I will se what speeds I can get. Note also that some rotaries alternate between emitting button presses and button releases. For such rotaries, you can assign to both the press and release to double the throughput. John

Yes - you always add the value to THIRD_PARTY_EVENT_ID_MIN, which is defined as the hex number 0x00011000 which is 69632 in decimal.

Ok, but I find this rather confusing as you previously posted some code (presumably from SIOC) that was trying to use the custom control numbers for presets. If you are using lua, why not just send these commands (either via presets or the Rotor Brake control) from the lua script? You can also add logging statements (using ipc.log) to check/test the performance, although I would not actually set Lua Plugins logging as this can slow things down even further. You can also use offset monitoring to see when offset A001 changes and get the timestamp of that, which could help see where the delay is coming from. Events and controls re the same thing... I think you mean preset (or calculator code), which will translate to the same event anyway - it will just go via the gauge execute_calculator_code function rather than via SimConnect. Yes. You can try that to see if the performance improves. You can also try moving the lua execution thread off of core 0/1 by setting an affinity mask - this may improve performance if the first cores re highly loaded. You can do this using the ini parameter LuaAffinityMask - see Ok.

If these reconnects are not causing any issues, it is nothing to worry about, just an observation from your log. Properly powered hubs are generally always better/more reliable than unpowered hubs, but it really depends on the devices you are using. If the disconnect/reconnect messages are just due to the iPad losing its connection/reconnecting, then this is nothing to worry about anyway as FSUIPC does nothing with that - it is just re-acting to a windows 'new HID device connected' message. John

This is generally not necessary, also in FSX, but can depend on the aircraft. For aircraft that use an axes/trim wheel, it is always better to assign to offset 0x0BC0 as this gives better control over the increments/decrements. For aircraft that use up/down for trim (as opposed to a wheel) or a switch with discrete positions, then bettor to assign to the inc/dec controls/events. There is no need to assign to the (default) key presses for this, unless the events aren't working via external applications (which can happen for some events/aircraft). For some aircraft in MSFS2020/2024, the standard controls don't work (neither the axes or inc/dec controls) and you need to use lvars/hvars/bvars/Input Events or calc code/presets, e.g. for the Cows DA42 you would need to use the lvar L:INPUT_TRIM_AXIS, or the MF preset 'Elevator Trim DN' (which uses that lvar). John

Yes - I should really load the myevents.txt file first and start the numbering from there. But, as I say, using the numbers is not recommended as these can change. The presets you saw in the log are the ones NOT loaded (and hence not available) due to some sort of errors. Loaded presets are NOT logged anywhere (there are usually far too many for this!). If you set WAPI Debug level logging (Log->WAPI->Debug), this will log the calculator code from a preset when it is sent the the WASM to be applied to the aircraft. Lua does seem to run rather slower in MSFS 2020/2024 than in other flight simulators (there are already several support topics on this), but it should not be that slow. They are a lot faster if they are already running and re-act to events, rather than being started on a button/key press (as they need to be compiled each time before being ran if/when assigned to run on a button or key press). Lua scripts may also run faster when FSUIPC is manually started, rather than being auto-started by the FS (although YMMV). Sorry but I can't really help much if using SIOC as I have never used this. Does FSUIPC not see your buttons? If so, you can try assigning directly in FSUIPC rather than assigning in SIOC.

Double check this and maybe also try running with standard privileges to see if that helps. As I said, the main reason for 3rd-party connection issues IS the privilege level. Nothing related to your issue. You do have a lot of USB device reconnection messages, which are strange, This could indicate either a USB power or connection issue unless you are disconnecting and reconnecting your Yawman Arrow. John

I've checked this here now and offset 0x0BC0 seems to work fine to control the elevator trim in both the C172 and JF Turbo Arrow III, I found your fast settings too low though, so changed the fast delta from 96 to 128 and also added fast assignments to the button release as well as the press. At one point I did noticed the trim starting to behave abnormally (wouldn't go below 0), but this rectified itself and I haven't been able to reproduce this since. So, please show me your ini & log files with the appropriate logging (mentioned above) activated. Also please add logging for offset 0BC0 (as S16). You an also use the version attached below which has some additional (temporary) logging added around offset 0BC) changes. John FSUIPC7.exe P.S. Once change from 7.5.1 to 7.5.2 that could cause this issue for you is the following: i.e. the ELEVATOR_TRIM_SET axes is now calibrated from 7.5.2 onwards, So, check your elevator trim calibration (on page 6 of the calibration pages) and remove/reset if you have this calibrated.

Your elevator trim assignments are the same for all aircraft: And I can't see how this can be related to the FSUIPC version, as you say: i.e. you see the same behavior when assigned in MSFS, no? Can you check that you do not have the trim buttons assigned in MSFS as well as in FSUIPC - they should be assigned in only one place. Can you set logging for Buttons & Keys and Events, and show me / attach your FSUIPC7.log file showing this issue, as well as attaching your full FSUIPC7.ini file and I will take a look. I will check the elevator trim here in the default 172 and in the JF Turbo Arrow (I don't have the Comanche). John

Your log file shows that you are using the events.txt file, as you have 18994 presets loaded: The control numbers for the presets in your myevents.txt file will certainly not start at 4194304 (which will be the number for the first preset in the events.txt file). If you want to use control numbers for the presets in the myevents.txt file, you should not use (i.e. delete and do nor install when you re-install). However, it is far better to use the preset name to send a preset, as I suggested, or just use the Rotor Brake control (with the appropriate parameter). You cannot see the presets being logged as you have disabled logging in the WAPI. To see the preset/calc code being sent, you need to set Debug level logging in the WAPI. The myOffsets.tct and myevents.txt are completely different.

The value will be different. You need to check the PMDG header file for the aircraft (PMDG_747QOTSII_SDK.h) to see what values to use. Otherwise, the technique for using custom controls is the same. See and also, to use custom controls via the Rotor Brake control, see John

Then why not contact support for the PIREP application? The ecceptions/errors you posted are from that application, not FSUIPC - that doesn't mean anything top me. It does look like this program has an issue connecting to FSUIPC, but it should handle that gracefully an not crash. This is an issue for the app developers, not FSUIPC. Note that the usual reasons for a third-party FSUIPC not being able to connect are: - the application is being ran at a different privilege level to FSUIPC. FSUIPC and all connecting programs must be ran at the same level. - firewall or antivurus software blocking the connection - not having an aircraft loaded and ready-to-fly You can post / attach your FSUIPC6.log file here if you like and I can check that for errors, but you should really contact the support of the app developers. John

Sorry, but I can't help if assigning in SIOC - I have never used and know very little about this. But you should be able to use FSUIPC's logging facilities to work out what is happening. Why do you think it is doing this? What does your log file show? You should see a line indicating the number of presets loaded, e.g. Can you show me / attach your FSUI{C7.log file. There can be many reasons why a preset is not working, you need to narrow it down why (is the preset actually being sent on the button press/release? Is it being received in the WASM? Is the WASM even installed? etc). Yes - that is the only location where this file is read from. Not sure what this means, but using the presets/calculator code is exactly the same as using the Rotor Brake control directly, and if you are having issues with those then you will have the same issues when using the presets.