John Dowson

It does not install that way, unless maybe you ran the installer with elevated privileges, which is not necessary and not recommended. But it is very difficult to understand what is happening when you do not respond to my questions. Are you running MSFS with elevated privileges? If you start FSUIPC7 manually, does it run with elevated privileges? Please follow my advise and then report back and attach files so that I can see what is happening (not screenshots).

I have moved this topic to the FSUIPC7 sub-forum. Please use this sub-forum for all FSUIPC7 support.

I have moved this post to the FSUIPC7 sub-forum. Please use this sub-forum for all FSUIPC7 support.

It also may be easier to use macros, which are another method of sending multiple controls/events. Save this attached file to your FSUIPC7 installation folder (before running FSUIPC7, or restart FSUIPC7 after installing): FSLA321.mcro Then start FSUIPC7, and assign your buttons/switches to FSLA321: Nose Swtch Up - to move the switch up FSLA321: Nose Swtch Down - to move the switch down You can then add other macros to the same file to control other switches. I have added Strobe and Beacon. John P.S. The Beacon switch controls seem to act like a toggle, so sending the Up when in Up position moves the switch down, and vica versa. So you only actually need one macro for this switch. Just FYI.

First, please don't embed your comments in quoted text - it makes if difficult to read and is just not necessary - put them outside please (as I do!). This is strange, but I do not think it is being blocked anyway as it is running - not sure why it says that in the properties. Also, please only attach files AFTER exiting FSUIPC7. No, you misunderstand me.... Are you using an XBox 360 game controller (gamepad)? Sometimes these are fake and can cause issues - if so, they can be ignored, And you cannot use these directly with FSUIPC - you need to install additional free software to use these with FSUIPC. That shows two copies running, which is vary strange and shouldn't be possible.... This does nothing but add extra logging. The JoyScan.csv file you attached is empty. This is worrying and is probably the cause of your issues, although I do not know why this is reported: Have you installed any specific drivers or additional software for your devices? If so, please uninstall any drivers and let windows install default drivers, and do not use any additional device software when using FSUIPC as this can interfere. Also please check that if they are USB2 devices they are connected to a USB2 port, and if USB3 they are connected to a USB3 port, and that if using a hub make sure the devices are properly powered. Can you also please just test running FSUIPC for the time being, i.e. no need to run MSFS. Just start FSUIPC7 manually without MSFS running for these tests, and ALWAYS exit FSUIPC7 before attaching files. Please do the following: 1. First uninstall any specific drivers for your devices if you are currently using any vendor supplied drivers. 2. Run the windows registry editor and take a back-up of your registry. 3, Unplug your devices. 4. Download and run (i.e. double-click) the following file: removeDevices.reg This will remove the current registry entries for your devices. 5. Reboot. 6. Delete your FSUIPC7.ini file. 6. Reconnect your devices, making sure they are connected to the correct ports, if possible (i.e.USB2 to USB2, USB3 to USB3). 7. Run FSUIPC7. Once it starts, exit and then show me / attach your FSUIPC7.ini, .log and .JoyScan.csv files. 8. Run FSUIPC7 with elevated privileges/as Admin, and again show me / attach your FSUIPC7.ini, .log and .JoyScan.csv files. John

This is nothing to do with "programming". It is assigning to the logged FS control/event with the logged parameter. I don't know why you tried this - that obviously won't work. There is no SDK for the FSLabs and therefore no custom controls. It may be possible to use custom controls, but you would have to determine the control number and it certainly will not be the parameter used via the Rotor Brake control. Please re-read my previous comment as it looks like you did not understand this at all: I said use parameter 72510 as you said this was logged when you use the taxi light switch in the VC. Why are you using 72511 when you said this was 72510? When I move the Nose light switch from Off to Taxi, I see this logged: and moving back, I see this: I am not sure why 2 controls are logged, but assigning to the Rotor Brake control with parameter 72512 moves the Nose light switch up, and assigning to 72511 moves the nose light switch down. So try that. If that works, you can just leave it at that. However, as two controls are logged when you move the switch in the VC, I would replicate this in the assignments. How you do this depends on what you are assigning to. The easiest way, if using a momentary push-button, would be to assign using one parameter for the press and another to the release, with both using the Rotor Brake control. The other way of doing this is overloading (i.e. having more than one assignment on a button) via editing the FSUIPC7.ini file. Assign the button press to the first control, save (press OK), and then open your ini file in an editor. Then open the button assignments panel again in FSUIPC7. Locate the assignment just made - it will look something like this (the index number may vary, as well as the button used) 4=PB,10,C66587,72512 -{ROTOR_BRAKE}- Duplicate this line, and give the new entry a unique index number and change the parameter, i.e. 4=PB,10,C66587,72512 -{ROTOR_BRAKE}- 5=PB,10,C66587,72514 -{ROTOR_BRAKE}- Save the changes, and then in FSUIPC7 click Reload all buttons. You then have two assignments on the same button, but you will not see this in the UI. John

Yes - they were logged when I turned the Captain EFIS ND Mode switch, as I said. You assign to the Rotor Brake control and use 72510 as the parameter - that should then control the taxi lights. I didn't yest/check that as you did not mention that this was for the taxi lights. It is straightforward - whatever you want to assign, operate in the VC, see what is logged and then assign to that. In most cases it will be a Rotor Brake control with a parameter, so assign to the Rotor Brake control and use the parameter logged. John

Ok - I have seen FSUIPC7 being blocked before, but usually iy is easy to unblock. I am not sure why you cannot do this and I cannot advise - please google to resolve this. Also, check any anti-virus software toy have running to see if this is interfering. You attached the ini file twice and not the evtx file.... The Joyscan.csv file only shows two (?) xbox controllers, which is strange. Are you using any xbox controllers, and if so how many? This could be a registry issue. Could you add the following to the [General] section of your FSUIPC7.ini file and generate another log for me please: LogCustom=x200000 It really shouldn't be - the default is enabled with no entry in the ini file (I think)... What devices/controllers do you actually have? From your log: The serial number should certainly not be a string, which may be the issue. Was anything previously working? It is strange that a rudder was previously detected - from your ini: Anyway, show me the files with the additional logging and we can try cleaning your registry to see if that makes a difference. I can show you how to do this - tomorrow now as I have now finished for the day. John

What does this mean? And this? The log file you attached seems to show FSUIPC crashing when scanning for your devices. I have no idea what could cause this and have not seen this before. Can you please check the windows event viewer for any events related to FSUIPC and show them to me - there should at least be a crash report. Can you also please attach your FSUIPC7.JoyScan.csv and FSUIPC7.ini files. Also: Why have you disabled the WAPI? That is need for almost all aircraft in MSFS2020/2024. John

I just took a look at the FSLabs A321 and tested the Captain EFIS ND Mode switch, which uses the Rotor Brake control with parameter 71026 for a clockwise turn and 71027 for an anti-clockwise turn. Assigning to this in FSUIPC also controls the switch in the same way. So yes, you can use the Rotor Brake controls with the parameters you see logged.

I have also just noticed that you are running FSUIPC7 with elevated privileges: Why is this? Are you running MSFS with elevated privileges? Everything needs to be ran at the same privilege level, and always better to run with standard privileges unless absolutely necessary.

Oh...and when you re-install, after the uninstaller has ran, double-check that the fsuipc-lvar-module folder has been removed from your Community folder. If not, manually delete that before continuing with the installation. The uninstaller may not be able to remove that due to your permissions issues.

Of course I did - but that tells me nothing. What tells me what is happening is your log files. Screenshots are useless so no point posting then unless specifically requested. The firs log file you attached was also useless as it showed that FSUIPC7 didn't even connect to MSFS. The second log file is the only useful bit of information you have so far provided, which shows that there is an issue with the WASM. Since then, I have been trying to determine if the WASM is actually running. If it is not running, that is your issue and we need to determine why. If it is running, then I need to see the FSUIPC_WASM.log file to diagnose the issue. If no log file (presume you mean the FSUIPC_WASM.log file, AND you are looking in the correct folder) is generated, then the FSUIPC WASM module is not running. You can also verify this in MSFS2024 itself: activate DevMode and under the Debug menu select/check Display WASM Debug Window, and then in the Modules selection select fsuipc-lvar-module (FSUIPC7_WASM.wasm). Then select the tab Module Section. What is the status there? As I said, I have no idea why this is - this is something peculiar to your system and something you must resolve. This could also be what is causing your issue, as the WASM may not be running due to permissions issues. Did you run the FSUIPC7 installer as Administrator? If so, this is not needed and may be the issue. Why don't you try re-installing? Just download the latest installer and run it again (not as admin). It will then ask to uninstall the current version (agree to this) and re-install. Then check the permissions on the file again. If you get the same issue, then sorry but I have no idea what is happening and there is something strange going on in your system related to permissions that you need to resolve. I cannot help with this. No, it is correct. But there are two auto-start methods, via the EXE.xml and via the .bat file. One of the bat files you attached shows that you were using the bat file auto-start method, and you have also modified this to start some other programs: That is why I asked.....

How are you starting this lua script? Can you also attach your FSUIPC7.ini please, and also another log file but with logging for Buttons & Keys activated as well as Lua Plugins. But why don't you use the lvar logging facilities provided in FSUIPC7? This will log to the log file and optionally also to an ext window. See the section Logging Lvar Updates in page 48 of the Advanced User guide. Yes, the simconnect display facilities are not available in MSFS.

Yes, with the PMDG aircraft you can use either custom control numbers (preferred) or the Rotor Brake control method - there are FAQ entries for each method. I don't know if the FSL aircraft support custom controls (I will check when I have time), but if the Rotor Brake controls are logged, then I would try assigning to those, using the parameter logged. Please just try this to see if it works and let me know. If not, let me know one button/switch that you are trying to assign and I will look into that here. John

Sorry, forgot to update this thread - see

I have no idea - just look at the FSUIPC_WASM.log file, if there is one - this will tell you if the WASM is running and if that ini file is being read. If you have no log file (in the WASM persistent storage area, NOT under your Community folder) then the WASM isn't running and that will be your issue. Why not? Did you read the documentation? If so, what isn't clear about that? You CAN modify that file, but it is NOT recommended, and you should use the one in the WASM persistent storage area (which is NOT there by default - you have to copy the one from the Community folder location to the persistent storage area and then modify it from there). This is all explained in the documentation. There is no file attached, and there is no point attaching it either. Attach the FSUIPC_WASM.log - that is the file I need to see, preferably with Debug logging activated, but any existing one would to do start with.... Also, why are you using the bat method of auto-start rather than the default (and preferred) EXE.xml method? Why are you starting other programs from the MSFS2024.bat file? It is better to use the facilities provided by FSUIPC to start other programs (and use either the CONNECTED or READY keywords, depending in the program). See the section Programs: facilities to load and run additional programs in the Advanced User guide.

That is strange... but I don't know what you mean by 'Could this be the issue?'. You (or the account that you used to install) are the owner. I cannot help with permissions issues on your system - try google. BUT, you don't need to edit/change that file, and it is not recommended to modify that file anyway as any changes will get overwritten the next time you install. Please read the section WASM module ini file and parameters in the Advanced User guide (page 51) where it says: It is recommended to leave this file as is, and copy to your persistent storage area and modify as and when needed from there.

Sorry, but this is confusing. Is the dll in the modules folder or not? If not, you can manually install it if someone can supply you a copy of the dll, and you would have to manually update FS2004 to load the dll. This is way before my time I'm afraid and have no access to anything regarding FSUIPC3 (it is free and unsupported). Again, I have no idea, If FSUIPC is installed and loaded by FS2004, and the only issue is that it is unregistered, then you can try manually creating the key file. Create a file in the FS modules folder (where the FSUIPC dll is located) called either FSUIPC3.key (or maybe just FSUIPC.key) with the following contents: [User] Name=free user Address=fsuipc@free.com FSUIPC=Y8ZGSUWHTIQ2 John

That is a far better log! But I don't understand why you keep attaching the bat file though - that is installed by the installer and I have that here. It is not needed. That log file shows that there is an issue with the WASM and that the initial lvars were not received. Please show me / attach your FSUIPC_WASM.log file, and check that the WASM isn't crashing - this seems to be more frequent in MSFS2024 than MSFS2020. Also set Debug level logging in the WASM (via the FSUIPC_WASM.ini file) - see the Advanced User guide if you do not know where these are. Also see the following FAQ entry on the WASM crash and how to prevent: John

If that is what FSUIPC sees, that is what windows is reporting. First, try calibrating under windows (game controllers). That will determine the values that FSUIPC sees. But if that is the range you see in the assignments panels, you can calibrate those to the full range using FSUIPC's calibration facilities. Better to assign using 'Send direct to FSUIPC calibration', but you may also be able to calibrate when using 'Send to FS as normal axis' (although I am not sure about this when using ProSim). Also, please check in ProSim. I don't use ProSim (although Pete does, the original author of FSUIPC)m but was under the impression that ProSim provides its own assignment and calibration facilities these days, so you may be worth switching to them, or at least checking that they are not interfering. Ask about this on the ProSim forums (or maybe try a different rudder axis control to see if that helps). John

Sorry but it is difficult to understand what your issue is. Is this with software that you have written using Paul's .Net client dll? If so, when you get the issue, can you still use lvars via FSUIPC or using the WASMClient? Basically you need to determine if the issue is with your software or if the WASM has crashed. So please do that. If the issue is with your software and you are using Paul's .Net client dll, I cannot help you, and you need to post in Pail's .Net dll client forum: https://forum.simflight.com/forum/167-fsuipc-client-dll-for-net/ That is also a question for Paul's forum. Many of your posts are very difficult to read and it takes a lot of work just to try and understand them. I understand that this may be a language / translation issue, but please take care to post in a format that is at least readable...e.g. at least no scroll bars please.... And this is VERY important: 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. You MUST make sure that any/all clients are NOT requesting lvar updates as this should be controlled by the WASM, not the client(s). John

The source is provided so you can recompile it with the latest compiler. However, I did recompile this recently (for FSUIPC7), so I have attached this below. Sorry, but I just don't have the time to provide an example. I have never used most of the provided SDKs and they are provided as-is, and most donated by other authors. You need to first write the new value to a user offset (e.g. 0x66C0) using FSUIPC_Write, then write the offset address used + the value format (as described in the offset status document) to offset 0x0D6C (again, using FSUIPC_Write), and then the lvar write request, which would be "::ASD_SWITCH_EXT_POWER", to offset 0x0D70 (using FSUIPC_Write), and then call FSUIPC_Process to apply. Note that the only supported SDK is the .Net / C# one provided by Paul Henty - there is a sub-forum for this interface: https://forum.simflight.com/forum/167-fsuipc-client-dll-for-net/ UIPC64_SDK_C_version2.zip

Your log file show s that FSUIPC wasn't even connected to MSFS and was attached when FSUIPC7 was still running: Nothing is going to work if FSUIPC7 is not connected to the FS. And please, ALWAYS exit FSUIPC7 BEFORE attaching files. How long does it take for MSFS2024 to get to the main menu after starting? You may need to trim the start-up parameters - see the Advanced User guide or the followig FAQ entry: If FSUIPC7 cannot get a connection, this is usually due to other badly behaved add-ons using up all available connections. What other add-ons are you using? Also, please at least check your log files if you have issues, and always check them before sending them to me. That one is useless.

Rather than using LuaValue and event.param, switch to using flags. Change the event.param call to use event.flag, and add 1 call for each flag used (the flag replaces the feed_value/ ipcPARAM value): -- -- function to convert to BCD -- function convertToBCD(freq) local cleanFreq = freq:gsub("%.", "") -- Remove decimal (e.g., "109.2" → "0920") local decimalNumber = tonumber(cleanFreq) -- Convert to number if not decimalNumber then return 0 end -- Return 0 if conversion fails local bcd = 0 local shift = 0 -- Convert each decimal digit to BCD format while decimalNumber > 0 do local digit = decimalNumber % 10 bcd = bcd + (digit * (16 ^ shift)) -- Use base 16 shift instead of bitwise left shift decimalNumber = math.floor(decimalNumber / 10) shift = shift + 1 end return bcd end function updateNav1(flag) currentNav1BCD = ipc.readUW(0x0350) -- read the current NAV1 frequency currentNav1 = string.format("%04X", currentNav1BCD) -- convert BCD to number (as string) if flag==1 then -- if turned right, the left encoder (MHz) sends the value 10 to offset 0x0D6C -- the following lines increase the MHz value by 1 MHz and wrap the frequency around, substracting 900, when 117 MHz is reached if tonumber(currentNav1) >= 1700 then newNav1 = currentNav1 - 900 -- currentNav1 will be converted to a number else newNav1 = currentNav1 + 100 end elseif flag==2 then -- if turned left, the left encoder (MHz) sends the value 20 to offset 0x0D6C -- the following lines decrease the MHz value by 1 MHz and wrap the frequency around, adding 900, when 108.95 MHz is reached if tonumber(currentNav1) <= 895 then newNav1 = currentNav1 + 900 -- currentNav1 will be converted to a number else newNav1 = currentNav1 - 100 end elseif flag==3 then -- if turned right, the right encoder (kHz) sends the value 30 to offset 0x0D6C if string.find(currentNav1, "%d%d95") then -- this line checks whether the frequency ends with 95 and ... newNav1 = currentNav1 - 95 -- ... if so, substractss 95 kHz so as to prevent the frequency from carrying (changing the MHz value) when digit wraps. So you can turn the encoder for the kHz value seperately without increasing the MHz value. else newNav1 = currentNav1 + 5 end else -- if turned left, the right encoder (kHz) sends the value 40 to offset 0x0D6C, which for now is "else" if string.find(currentNav1, "%d%d00") then -- this line checks whether the frequency ends with 00 and ... newNav1 = currentNav1 + 95 -- ... if so, adds 95 kHz so as to prevent the frequency from carrying (changing the MHz value) when digit wraps. So you can turn the encoder for the kHz value seperately without decreasing the MHz value. else newNav1 = currentNav1 - 5 end end newNav1_BCD = convertToBCD(tostring(newNav1)) -- convert to BCD ipc.control(65708, newNav1_BCD) -- sending BCD to FSUIPC end event.flag(1,"updateNav1") event.flag(2,"updateNav1") event.flag(3,"updateNav1") event.flag(4,"updateNav1") ipc.log("Nav1 update lua script now running") Then write the flag value (1,2,3 or 4) to offset 0x0D6C, and use the LuaToggle control when writing to offset 0x0D70. John