John Dowson

I am not familiar with the SDK you are using, but this: Offset 0x0D70 is only 128 bytes, not 256. This also doesn't seem correct: To update an lvar, the value must first be written to offset 0x0D6C. But I am not familiar with the SDK you are using, or which FS you are using (there is probably an easier API to access lvars if using MSFS). Maybe @Paul Henty could comment as I presume this is using his dll.

Well, you have configured it to log events, and if you don't want to see them you can always turn off Event logging. With Event logging, FSUIPC logs all (non-axes) events seen by FSUIPC (which should be all events applied in the FS). Many aircraft in MSFS continually emit certain events, and these events differ with each aircraft. If you want to ignore such events when Event logging is set, you can use the DontLogThese ini parameter. This can go in the [General] section, which will then apply to all aircraft, but it is better to add this to the profile section (i.e. under [Profile.xxx]) as the events to ignore are always aircraft specific, e.g. DontLogThese=65957,66519 ,66068 Such logging really shouldn't give performance issues though on most modern systems... Excessive logging in MSFS can cause performance issues, so also check the MSFS logging console.

Which SDK are you using? If using Paul Henty's client dll then you should post in that forum (I can move this post id you like). Other than that, the error should be obvious (as indicated by the message), but as your process calls are in the loop and process one read/write at a time, I don't know why the data limit is exceeded. But I am not familiar with the SDK you are using. Pete retired more than 5 years ago now. There are various wrappers around the basic FSUIPC SDK, some of which provide an event-driven interface. with Pai; Henty's dll being the most advanced.

No, axes assigned to presets are not calibrated - only the standard FS controls go through calibration. You can also reset any calibration entries to stop calibration by FSUIPC if required..

Why is it not compatible? As I said, for PMDG panels you need to look at the provided custom controls and use them. Isn't that possible via the CDU/FMC software? If that can write to FSUIPC offsets, you should be able to configure to do that if you cannot assign to custom controls or presets directly. Do you mean the 787- Dreamliner? There is no Asobo 737... If so, logging reveals this: So you can try assigning to FUELSYSTEM_VALVE_TOGGLE with a param of 1 or 2 (for engines 1 & 2 respectively) to toggle, or assign to the Input Events FUEL_Valve_L and FUEL_Valve_R with parameters 0 and 1 for assignments to fixed positions. Is that from Bredok3d or Asobo? As I did with the 787-10 dreamliner, try using the logging facilities to see what is being used. John

Here's the DA42 bindings file: DA42 LVAR bindings.txt

Are any other controls/events logged for this, or just the Aileron Set? That is very strange...assigning in FSUIPC should not affect assignments any where else, although calibration can affect controls assigned outside of FSUIPC. Ate you sure that this was not for other reasons, such as the window focus not being with MSFS (with the xbox controller being an XINPUT device, MSFS needs the focus to receive the xbox controls)? Also strange. Take a look at the COWS discord server - there are reports there of similar issues. For aileron, rudder and elevator, you need to assign to use the following lvars: L:INPUT_AILERON, percent; -100 - +100 L:INPUT_RUDDER, percent; -100 - +100 L:INPUT_ELEVATOR, percent; -100 - +100 You can assign an axis to control an lvar by defining your own preset and assigning to that. Take a look at the following FAQ entry on how to do this: John Later: found this: DA40 LVAR bindings.txt Thats for the DA40, but the COWS DA40 will share the same LVARs as the COWS DA42, so also applies.

Please also check/confirm that all your computers are in the same windows Workgroup. As your issues started after a windows update, it must be due to config of that machine, which would either be the workgroup or the firewall. Did you also download and install the latest windows VC++ redistributables after the update? This may also be needed and does no harm, so if not done already please also try that. John

Better to stop/disable the firewalls, and also check the firewall in your router. You should also add "Protocol=TCP" to your WideClient.ini. Why did you not include your WideServer.log file? As I said to the previous poster, I need to see all 5 files from the same session. Remove those and stick to TCP defined by the client(s). No idea what could cause that...Do you see the FSUIPC icon in the system tray when it is closed?

But you said: ! There is no Asobo 737 as far as I am aware, so which aircraft are you using? Id the standard controls/offsets don't work, you will have to look into each aircraft to see what works for that aircraft. For the PMDG 737, there are these presets for the cut-off: They are potentiometer presets (i.e. for an axis) and should not be used directly in FSUIPC, but if you look at the calc code for those presets you should be able to define your own presets either to be used on an axis or you can define presets for cut-off and idle to be used on buttons. I can help further with this if you want to go down this route. For other aircraft, you need to use FSUIPCs logging facilities to determine how to control the cut-off, i.e. set the logging options, open the logging console and cut-off in the VC and see what, if anything, is logged, and then use that, Or you can inspect the aircraft code to try and determine how this can be assigned - see https://www.badcasserole.com/uncovering-input-events-using-the-msfs2020-model-behavior-dialog/ That uses "Set Mixture Lean" which also won't work for many add-ons. You need to determine what actually works for your aircraft. John

Sorry - that is in the latest README.txt and is not in the current released version. Note that this issue was previously reported here: John

Then either you need to tune FSUIPC7s start-up parameters, or there is an issue with another add-on taking up all connections. What other add-ons are you using? Please attach your FSUIPC7.log file, and also your MSFS' EXE.xml file (look in the InstallFSUIPC7.log file if you don't know where that is located - it will be logged there). The following article describes how to tune FSUIPC7 start-up parameters, but it should really auto-tune itself in most circumstances:

No need to be sorry - you can still tag me, its just that its generally not necessary as I read all posts on these forums anyway! John

I don't have the COWS DA42, so it is difficult for me to advise. You need to use logging to determine what is being used. First, load the aircraft onto the runway and open the FSUIPC logging window (Log->Open Console) and set logging for Events. If you see many events logged without touching anything, these events are just noise and can be ignored. When you need do is exit FSUIPC7, then add the DontLogThese ini parameter to your DA42 profile section to stop thse events being logged. Once that is done, restart FSUIPC7 and also set logging for Axes Controls. Then move the axes (rudder, elevator, aileron) in the VC and see if any events are logged. If so, you can try assigning to that. If no standard controls/events are logged or work, look for Input Events instead. Try logging for Input Events and again move the axes (rudder, elevator, aileron) in the VC and see if any input events are logged. If so, I can show you how to assign to use those. If no Input Events are available. try looking for lvars. List the lvars (Add-ons->WASM->List Lvars) to see if any look applicable. If some look like they might control the main axes, you can log those lvars (see Advanced User guide on how to do this) and again move the axes on the VC to see the value range of the lvars. If it looks like you can use lvars to control the axes, I can help you assign to those. The last step would be to inspect the code of the aircraft to see how the axes work. See the following article on how to do this: https://www.badcasserole.com/uncovering-input-events-using-the-msfs2020-model-behavior-dialog/ Note there are a few presets currently available (45) for the COWS DA42, but none for the main flight axes. Actually, before trying the above, try assigning with "Send to FS as normal axis" and try the various different axes control there, including the *_EX1 ones. You can (possibly) still calibrate when assigning this way, if allowed by the aircraft. John

From the README.txt: What has this got to do with this topic ("FSUIPC7 Trial License Available Here")? I would appreciate it if you do not hijack unrelated topics, and always check the documentation and consult/search these forums for similar issues before posting. 90% of posts are either repeats or documented. Thanks, John

Use the while construct - from https://www.tutorialspoint.com/lua/lua_while_loop.htm: The do statement can be a sleep (e.g. ipc.sleep(25)) to wait a short time to not consume so many resources and to give time to other threads so that the condition can become true. The loop will exit and the lua code continue when the statement is true. Such a loop is useful in many circumstances, for example to wait for an lvar to become available (not all lvars are initially available!), use: -- Check Lvar exists id = ipc.getLvarId("L:FS2CEW_RAASPRO_MASTER_SWITCH") while ( id == nil or id > 65535 or id < 0) -- Note that just a nil check should be sufficient from 7.5.2 onwards do ipc.reloadWASM() -- request to scan for new lvars ipc.sleep(200) -- wait before checking again id = ipc.getLvarId("L:FS2CEW_RAASPRO_MASTER_SWITCH") end -- lvar now available By the way, no need to tag me - I read all posts anyway! Cheers, John

The L: needs to be in the quotes, i.e. John

Not exactly - you also need to tell me what you have tried, and those files are missing the WideServer.log file. Please attach that as well - and I need to see all files from the same session. so you probably need to re-attach ALL files. Did you try with all firewalls disabled (client, server, router)? If not, please do that and also confirm that firewalls were all down when you tested. Your WideClient.ini shows that you have not specified the Protocol ini parameter, and you have misspelled ServerIPAddr as ServerIPAdd, so also add/correct those before testing again. John

I know - repeat on key assignments is the default. You have to manually check the No repeats! checkbox to disable repeats on key assignments. This is a legacy issue....I should probably make no repeats the default for key assignments, as it is with buttons.

Well, you haven't searched that well... This exact same issue has been reported many times, and my response is always the same. RTFM!! Read the documentation and follow all the trouble-shooting steps there, e.g. check workgroup, disable firewalls, set ServerName/Protocol, etc Once you have tried all that, if still not working, report back, telling me what you have tried and attach the 5 files I need to see: FSUIPC7.log, FSUIPC7.ini, WideServer.log, WideClient.log, WideClient.ini.

If the WASM crashed, there will be no closing statement, and if the closing statement is there, the WASM didn't crash. Are you saying that you still have your issue when the WASM didn't crash? The WASM crash seems to happen more often in MSFS2024, although I still can't trigger this here. I will take another look, next week, time permitting, and investigate this further. Then please show me / attach your FSUIPC7.log file from the remote PC - you seem to have attached the one from the FS PC. Your WASM log does show some issues: One of your FSUIPC clients is requesting lvar updates (via WAPI ini parameter LvarUpdateFrequency) - you should remove that/set to 0 and let the WASM control all updates. What did you change? There are two locations for the FSUIPC_WASM.ini file. if there is on in the permanent storage area, under you user' AppData folder, then this will take presidence. The values used are logged in the log file: Please show me/attach the following files showing your issue: FSUIPC7.ini & FSUIPC7.log: both from the PC that is requesting the lvar changes, and with the following logging activated (only!): Buttons & Switches Events Extras WAPI -> Debug FSUIPC_WASM.log file: with Debug level logging activated P.S. I have moved this post to the FSUIPC7 support sub-forum

Those offsets use the standard FS controls. These will not work with the PMDG 737 for MSFS. You will need to use either custom controls, lvars or (easier) presets, which can set lvars fire custom controls as well as others, for these functions. Check what presets are available for these functions in the HubHop website, or in the 'Find Preset' window in FSUIPC. if you need to do this via offsets (as opposed to direct assignments), then you can use offset area starting at 0x7C50 to send presets.

By the way, it looks like you have all your key presses assigned with repeats. Most of those, if not all, should be no repeats. You can change these via the UI, but probably easier to just insert an N in front of the VK number, e,g, to Do this for all key assignments that don't need a repeat, and when FSUIPC is not running.

I don't understand why that is logged (and so many times!) - I have tested with similar comments here and don't see anything like that logged. I will check further to see if I can reproduce, but if its not causing any issues (i.e. you profile assignments are working as expected and you can see the assignments in the button assignment panel) then I wouldn't worry about this too much. John

I have implemented this now, but function keys F13-F24 are still not being received. I will report this to Asobo. VK12 is being received in this version. So it looks like you can't use F13-F24 at the moment - try assigning to other keys. John FSUIPC7.exe Reported to Asobo here: https://devsupport.flightsimulator.com/t/cannot-receive-function-keys-f13-f22/13023