John Dowson

Is the script receiving any data? Try debugging the script, by either starting it with LuaDebug or by setting Debug / Trace Lua plugins in the FSUIPC logging tab. But it would be better to update your C code and use the FSUIPC SDK to update the offset with the COM! stndby frequency. Take a look in the SDK subfolder, at the UIPC64_SDK_C_version2 toolkit. You can use this to update FSUIPC offsets, which will trigger the controls to set the values in the FS, John

You are writing the values as an unsigned byte (UB). Those lvars contain double values, so use ipc.writeDBL or ipc.writeFLT. And as they are 8 or 4bytes, you need to write them to an offset on an 8-byte or 4-byte boundary, so use, for example, 0x2750 and 0x2758 (last digit must be a 0 or an 8 when. writing as doubles. That won't do anything.... That will write those lvar values to new lvars (and create them)...why would you want to do this? Again, because you are writing them as bytes when they should be doubles (or floats)... Try: or John

Your files show several things... First, please be more selective with your logging. You seem yo have activated logging for most things for some reason - only activate logging that you need and remove the rest. So, for button assignments, you usually only need logging for Buttons & Switches and Events. Remove the rest. It is also far easier if you look at the log in real-time, so you can actually see what is happening when you press a button, To do this, open the logging console (Log->Open Console). Looking at your files, it also seems that you have changed things while running, so it is difficult to understand some things in your log. Initially, you had your button assignment to the ELECT_FUEL_PUMP_SET control on repeat: but you later corrected for this: but what I don't understand is the following controls being sent: It is these that are causing the VC switch to flicker so much. Do you have assignments in MSFS or elsewhere? If so, please remove these. Also maybe check any assistance options in MSFS - these could also be interfering if set. Your ini file also shows a strange entry - remove this: For your assignment to button/switch 13: you are assigning to the set on press but the toggle on release - you should use the set with both, but with a different parameter, i.e. Also, are all your button assignments using switches or sticky buttons? I ask as you are assigning all of them on press and release. This is ok for switches/sticky buttons, but not for standard/momentary buttons (which send a press quickly followed by a release). For such buttons, you would normally only assign on the press only. For the throttle control, you can try this Input Event: To use this, you first need to determine the range of that Input Event. To do this, activate logging for Input Events (Log->Input Events), then move the throttle in the VC through its full range, and look at the parameter range for that Input Event. Then assign your throttle to write its value to an FSUIPC offset, and you need a lua script that monitors the offset (using event.offset) and in the handling function you calibrate the axis value to the input event value range, then send the input event to the FS using ipc.execInputEvent. I can help with such a script if needed, and if you let me know the input event parameter value range as well as your axis value range.. These assignments also look strange: You have a repeat assignment set on press for button 1, and the same assignment on release on button 0, both sending a 0 parameter.... Also, please wait for 5-10 seconds after aircraft load before trying to do anything - FSUIPC is only fully ready once the following is logged: John

If something doesn't work as expected and you want me to help, then please attach your ini and log files (with appropriate logging activated) so that I can check your assignments. Did you also give the parameter as 1? And did you remove the assignment in MSFS if assigning in FSUIPC? How does your toggle switch work? Usually they send a button press in one direction, and a release in the other. If this is the case, then you should assign to the toggle on both press and release. However, when assigning to a toggle control for both directions, it is possible for your toggle switch to be out-of-sync with the aircraft, so it is usually better to assign to the to the set control (ELECT_FUEL_PUMP1_SET_ with a parameter of 1 in one direction and 0 in the other. But if that isn't working, use the toggle control. Note that some toggles switches may send a different button press/release in each direction, in which case toy need to assign to both of the registered buttons. Not sure why its doing this...it could be due to having dual assignments which are conflicting (i.e. assigned in both MSFS and FSUIPC) or maybe you assigned on FSUIPC with Repeat... Maybe try posting on the MobiFlight discord server, in the MSFS2020 channel. That is the place for asking for help in defining presets for assignments where standard controls don't work. I can see there are already some presets defined for the Cowan Sim. H125, but nothing yet for the MD500e. As I said, I cannot help much with aircraft that I do not have access to - I can only check that FSUIPC is working correctly and that you have assigned correctly - and I need to see you ini and log files for this. John

Ok - that makes sense.

Ah...that is even more difficult! I don't know how you would detect a light touch on a physical button using windows. FSUIPC uses the HID Joystick API, and can only detect button presses and releases. And, as you say, there is no SimConnect interface to control the highlighting. The latter part may be possible in a WASM module using one of the other available SDKs, but I don't know if its even possible for a light-touch (on a physical button) to be detected in windows! Regards, John

No - only a subset of simulator variables are held in offsets. I have never used or looked into using VR with MSFS (or any other sim). FSUIPC doesn't really support VR use - it supports physical controllers, and provides data for other 3rd-party apps (FSUIPC clients). There is no way that FSUIPC can detect a 'light touch' in VR, and also no way for it to highlight anything or show any further information (tooltips?). Basically, FSUIPC doesn't do anything with "visuals'. Look into MSFS's tooltip options, and I believe there are also some 3rd-party mods in this area. Otherwise, try posting in the MSFS/Asobo forums for advice, in the VR forums. Sorry I can't be of more assistance. John

...and if you have written your own program to drive the LED connected to the arduino, you could use the FSUIPC SDK to just write the com1 standby frequency to offset 0x05CC (or 0x311A). Note that you can also use the following control to set the frequency using Hz rather than in BCD format: 67363 COM1_STBY_RADIO_HZ_SET

Ok - glad you got it working, and thanks for the update. Strange it works with the standard controls though, and the custom controls they provide don't work.... John

I am not sure how you are getting the input to set your LCD display, but It may be easier to use the ipc.ask lua function to get this user input / com frequency in one go (rather than monitoring keyboard input via event.key), and then use the value received to set your LCD display (however that is done!) and send the control to set in the sim. You would need to run such a script on a specific key combination or button press. Cheers, John

First, you posted in the sub-forum for FSUIPC7 / MSFS - please use the main forum for all other versions of FSUIPC, not the specific sub-forum for FSUIPC7. You also attached the trial license/key file for FSUIPC7 for some reason...I have removed that. Yes, that is the correct control/event, but be aware that the parameter for that control is in BCD16 format (Binary-encoded decimal), so to set to 120.80 you would use: ipc.control(66371, 0x2080) (the leading 1 is assumed). That is the difficult bit. You would need to register a function to receive key presses (using the event.key function) for the keys 'C'. 'O', 'M'. '1', ' ', 'S', 'B', ',' , and all the digits, then keep track of everything entered and in the correct order....I really can't recommend doing it this way.... Maybe take a look at this user' contribution, which is a lua script to allow keyboard entry for radios (as well as obs and AP). Its for FSUIPC4, but should work with FSUIPC5, although some small modifications may be needed: John

Well, its not going to be anything to do with the throttle itself - that will just be sending an axis value, as with all other throttles... Doesn't matter - and you don't have to. As the flaps are working for the user in the other post, it would be interesting to find out how this is assigned. If its not using LINDA, you can just copy that. if it is using LINDA, I can maybe take a look at what LINDA is using and replicate that (LINDA is just a fancy wrapper around FSUIPC's Lua functionality). The Rotor Brake control is another method of sending custom controls for PMDG aircraft - see That is strange...be careful though, as I think there were some issues when using the regular flpas assignments that could cause a loss of power when climbing...but that may have been for the 737 or for the MSFS version, not sure without checking... Was that with the standard flaps control? Could it either be due to a failure or maybe they are being controlled by the FMS? I am no expert on airliners and only fly these occasionally for test purposes, so better off asking about this on the PMDG forums, and check the 777 documentation.

You don't create them - they are either provided or not. Just try listing what is available: Log -> List Input Events and Add-ons->WASM->List Lvars. For Input Events, you can also log these in real time (Log->Input Events), so set that and then move the twist throttle and see if anything is logged. The FSUIPC7 main window also indicates how many Input Events and Lvars are available (as well as Presets and Hvars). No problem - sorry I can't help more, but its difficult not having the aircraft. I can only advise on the various techniques to try, and how to use those if you find anything. Regards, John

Note that another user also had issues with flaps in the PMDG 777, in the following thread: I have asked if he can share his settings, although he way be using LINDA for this... John

@Edmundo Could you maybe share your flaps settings as another user is also having issues, in this thread; Thanks, John

By the way, saw this on the flightsim forums (https://forums.flightsimulator.com/t/cowan-simulation-md-500-e-helicopter/572344/15😞 That was quite old (for V1 in Jan 2023, but maybe worth checking if this has been fixed... John

Very strange that it logs the throttle inc/dec commands - but you shouldn't use these on an axis/potentiometer. Not all axis that work when assigned in MSFS work when assigned by 3rd party apps - this is a known issue. For "set helicopter throttle axis", try using Helicopter Throttle Set - these are the specific 'helicopter' controls: If the standard controls don't work, lcheck for available Input Events and lvars. It is difficult for me to advise on this as I don't have this aircraft, and all add-on aircraft work in different ways. Maybe try asking on the aircraft developers support forum. You can also just assign this in MSFS - no problem mixing and matching assignments between FSUIPC and MSFS, as long as you don't have the same button/switch/axis assigned in both. John

Depending on what to control you are using, it could take a parameter, usually 0 for off and 1 for on... If the PMDG 777 custom flaps controls are not working, then maybe ask about this on the PMDG support forums.

Then I do not know why this PMDG custom control is not working. Maybe try the same control via the Rotor Brake method... I do not have the PMDG 777, but I can check this in the 737...however, I am currently away/travelling. I will look into this further when I return on the 23rd October (Wednesday next week). Sounds very strange though...are any of the PMDG 777 custom controls working for you? These have worked without issues for many years for most user.... John

Ok. Be aware that FSUIPC populates offsets for data based upon the standard simvars, which used to be used by most aircraft (but not all!). With MSFS2020, many more aircraft, some default and many add-ons, don't use or respect the standard simvars, and may use lvars, bvars (input events) or hvars (html variables) instead. If this is the case, then the default offsets won't work / hold the correct data. What you can do for such aircraft is determine what holds the correct data, add this to an offset, and then you can instruct FSUIPC to 'spoof' the reading of the original offset (that the 3rd party app is reading) to read the value of the correct value and supply this instead. If you want to do this, you need to know what offset is being read by the third-party app, and what holds the correct value. If you know this, I can help you with the rest... John

First, if this is a charity or not-for-profit organisation, I will give you a free license - no need to purchase. If this is the case, please PM me the details so that I can verify, and I will generate a free license for you. You also mention FSX - you need FSUIPC4 for FSX. This is the forum for MSFS2020 / FSUIPC7. Please clarify which simulator you are using - FSX or MSFS2020? They are very different beasts... With FSUIPC, you use a system called 'profiles' to have different settings/assignments for different aircraft. Just download and install the relevant FSUIPC version for the simulator you are using. The FSUIPC documentation will also be installed, which will tell you how to use profiles. And if you are using FSUIPC7/MSFS2020, start with the trial license which you can download from a sticky-topic at the top of this sub-forum. There is no trial license available for FSUIPC4 / FSX. John

Then you have a UserCfg.opt file in your user' AppData\Roaming\Microsoft Flight Simulator folder for some reason (did you previously have a Steam version installed?). Delete or rename that file and re-install. If that file is present in that folder, the installer (and FSUIPC) will think you are using a Steam install, hence the issue. John

You need to determine what to use for these controls. To do this, use FSUIPC's logging facilities. For the Twist Throttle, first try logging Axes Controls, open the logging console window (Log -> Open Console...), then twist the throttle in the VC and see if anything is logged. If so, try assigning to that. if not, try logging Input Events and again twist the throttle in the VC and see if anything is logged, and if so you can use that (I can help you in assigning an axes to an Input Event if you don't know how to do that). If there are no standard controls or Input Events, the next thing to try is lvars - try listing them (Add-ons -> WASM -> List Lvars) to see if any look appropriate, and if so try setting it (again using the Add-ons ->WASM menu entries) and you need to determine the value range of the lvar. If there is an lvar, I can also help you assign an axis to control this if needed. Not sure I fully understand this...you cannot easily map different ranges of an axis to different controls. To do this, you would need a lua script. Alternatively, you can just assign your axis to the twist throttle control (whatever that is!) and just send the throttle Cut control in an axis range (using the right-hand side of the axis assignment dialog). Throttle Cut is a standard control and should be available for button assignments and for axes range assignments. You cannot use this control as an axis assignment as this makes no sense - axis assignments take a parameter (the axis value) but Throttle Cut takes no parameter - it is usually assigned to a button (and usually a detent button on a throttle). Note I am currently travelling so support will be intermittent until Wednesday next week. John

Sorry but i have no idea what your issue is.... Be aware that FSUIPC is aircraft agnostic (generally, although it does have specific offsets for PMDG aircraft). If any offsets or controls are not working for a given aircraft, it is because the aircraft does not use that event or simvar. It will only detect these if the aircraft you are using uses the standard simvars for these data points. I have no idea what APLv2 is... What is wrong? Proof (i.e. logs)? Explain what you mean by 'gets data'? I think you are either mistaken, or the aircraft you are using is not implemented correctly...there has been no change in the lights offsets (0x0D0C) for many years (if that is what you are talking about). If they are reporting the wrong data, then the aircraft is setting the wrong data and needs to be reported to the aircraft provider. But I think it is more likely you are either misunderstanding something or have an error somewhere. What do you mean by ' If you have an issue, please show me your files - your FSUIPC7.ini and FSUIPC7.log files, the latter with appropriate logging activated for your issue...whatever that is... But what has this got to do with FSUIPC? FSUIPC just reports and responds to the events seen/received.... Sorry, but I really have no idea what you are talking about...please explain more clearly, if you think this is an issue with FSUIPC... Maybe.... PS: I am now on holiday/away for a long weekend, back on Wednesday....

First, please change this: to this: That won't make any functional difference, but you should understand why the other entries aren't needed.... I don't have the PMDG 777 so cannot test/try these controls to see if they work correctly. Please do the following: - start the sim and load the 777 - open FSUIPC7, and activate logging for both Events and Axis Controls - make sure you also check to Send to console window, so you can see the events when logged - move the assigned flaps axis through its full range, from 0 to 30 and then back again. - exit P3D, and then show me/attach your FSUIPC6.ini and FSUIPC6.log files and tell me what, if anything happened when you moved the flaps lever I don't have the PMDG 777 so cannot test those controls here. And I can only help you confirm if the correct controls are being sent as assigned (which i am sure they are, if assigned correctly). Also, please test/try those custom controls to see if they actually work, e.g. assign a button or key press (temporarily) to one of the flaps settings and see if triggering that moves the flaps. If not, then maybe something else is preventing these controls from taking effect... John