John Dowson

When you assign to Send directly to FSUIPC Calibration you MUST calibrate in the FSUIPC calibration page. That doesn't sound right at all - you must assign either in P3D or in FSUIPC, not both. I will see if I can get hold of the CRJ to investigate. John

Is that the macro file name or the macro name? Remember, a macro file can have many macros. You do not need to search your computer, just look in your FSUIPC5 installation folder (i.e. under a folder called Modules, under your P3Dv4 installation folder - here : C:\Lockheed Martin\Prepar3D v4\Modules\). Did you end the macro creation process, by clicking the End Macro Making button? The macro file is created once you do this - as explained in the User Guide: John

FYI, FSUIPC4 v4.977 has now been released.

For the stable A320neo, the MobiFlight hubhop preset list has this calculator code and comment for the A32NX THROTTLE FULL REVERSE BUTTON preset: (A:GENERAL ENG THROTTLE LEVER POSITION:1,percent) -0.1 < if{ -9830 } els{ -16383 } (>K:THROTTLE_SET) Intended for a button press. It will toggle throttle between full reverse and idle. If throttle lever is anywhere idle or above button press will activate full reverse. Pressing again will cancel reverse and go to idle. This doesn't seem to be available in the dev version. If using that, maybe ask about this on the MobiFlight discord channel. John

@light_blue_yonder Are you still having issues setting up your throttle in your add-on aircraft or is this now resolved? Did you check the thrust lever set-up document mentioned by Reingard? John

Ok, I now understand what is happening. It is actually a very old bug where an array is updated out-of-bounds, and the problem with vPilot/Squawkbox has only just showed itself due to the memory re-alignment in the new build. I have corrected this now in the attached build, which i will release officially in the next few days: FSUIPC4.dll Thanks for your assistance in tracking this down. Regards, John

It is fixed, but I won't be releasing yet as I want to understand why it broke, and if this could cause any further issues. I will let you know once I have done this. John

You didn't say you had tried anything, just that you didn't understand anything... Just look at the logging tab in FSUIPC. Check the box next to Events (non-axis controls). That will log your events. If you check Send to console window, that will open the (logging) console window. Please consult the provided FSUIPC User manual, at least initially, not google. Yes of course, what else would I be referring to? This is support for FSUIPC after all.... Skip the lvars if you are not familiar with them (although there is plenty of provided documentation on how to use these). Mouse macros are also explained in the FSUIPC documentation. John

I cannot see any spoiler assignment: ? And what is the Custom control? Did it go directly from the high number to 0? If so, sounds like the axis is registered as a digital / on/off axis. If this is the case, see: Also, try calibrating the axes you are using for flaps/spoilers first in the windows calibration panel. to see what range of values you get there. John

Ok, but this was only suggested as a temporary work-around. I will fix this, but now I know what is causing it I am trying to determine why this changed between the two builds... John

But why are you doing this? If you want to assign a key press to a button, just use the left-hand side of the Buttons + Switches assignment UI panel. Just do that and then take a look at how the assignment line looks in your FSUIPC5.ini file afterwards. You shouldn't do that either - these comments/annotations are automatically generated. No. You need a number - use 0 if assigning to a modifier on its own, and you need to add 8 to the shifts, so should be: 16=P7,13,K0,12 You need to do this one by editing your ini, as you need to give a non-modifier key when assigning in the UI. Maybe the ENTER key is assigned somewhere to the full throttle control? Try activating logging for Buttons and Key operations, as well as Events (non-axis controls) and see what is logged when you press the assigned button. If you require any further assistance, please also attach your FSUIPC5.ini file the next time so I can see your actual assignments. And, if you are manually editing your FSUIPC5.ini file, make sure that you reload the changes in the UI if FSUIPC is running. John

Ok, thanks. But that is the FSUIPC7 installer being quarantined. The OPs issue seems to be with FSUIPC7.exe, not the Install_FSUIPC7.exe. John

It is not difficult - just go to the logging tab and select the appropriate options. I'm sorry, but I cannot help you any further if you are not even willing to try even very simple recommendations.... John

Ok, thanks for the report. Let me know if/when you hear back from them. John

Hmm, even stranger... I had left FSX and vPilot running while I typed that last comment, where the Mode C issue was present, and just tried again and it now seems to be working as expected...! I can even update that offset (or use the Add-ons -> Squawk Mode C option)and can see the Mode C being activated/deactivated in vPilot. It looks like its the 255 value in offset 7B91 is causing the issue. Once that is reset to 1 (or 0), the Mode C button works as expected. I'll see where that value is coming from (and what has changed since the previous build...) and see if I can correct. In the mean-time, if you are using a registered version of FSUIPC4 try setting the value in that offset to 0 (via a key press or button assignment to Offset Byte Set) to see if vPilot can squawk Mode C once it has been reset. John

Just tried to reproduce this issue. While doing this, I am monitoring offset 7B91 (as UB), which is where the squawkbox data at offset 17 is stored in the FSUIPC offsets. In one test, the Mode C was actually working, and I could see this value changing from 1 to 0 and back again when I click the Mode C button in vPilot, so it seemed to be working as expected. However, on subsequent tests, pressing the Mode C button had no affect - no CDA data update received via the CDA and no change in offset 7B91. Writing to this offset manually also produced no change in vPilot, so it seems to me like the data exchange via the Squawbox CDA is not working correctly. You say that you can see this change but changes back again to 255. Is that via the vPilot CDA logging? Can you try logging the value at offset 7B91 in FSUIPC to see if the CDA change is reaching FSUIPC4 - it looks like it isn't reliably getting through, which is the issue, but I'm not sure the cause of this at the moment. Its very strange that this worked for me the first time and has failed subsequently. I will keep investigating. John

Please see this thread: https://forums.flightsimulator.com/t/using-link2fs-with-fs2020-to-connect-arduino-panels/337926/13 From that thread, it looks like Link2FS was updated for MSFS but has issues. Maybe contact the developer to see if these issues are being addressed... Well, if thats what Link2FS does it seems that its that application that you need, or an alternative that works for MSFS. I'm sorry, but nor knowing or using that application I cannot advise. Maybe ask on cockpitbuilders.com to see if there is an alternative, if Link2FS cannot be configured to function correctly with MSFS. John

Your ini shows you have 3 controllers: The U is the axis, but which controller was it from? If that keeps registering before you can move the axis you re trying to assign, this usually implies that the axis is jittering, i.e. sending values when not being moved. Click the Ignore Axis button to ignore this for the current assignment session. After you have done this, your other axes should (hopefully) register with movement. I see you are also not yet using the JoyLetters facility. You should really be using this - just change the AutoAssignLetters ini parameter value from No to Yes (or assign your own letters - see the documentation if you want to do it this way). Ok, let me know. Cheers, John

Sorry - you are using Windows 11. Please set that option. John

As you are using profiles in separate files, I also need to see your FSUIPC6.ini for your DA40 profile. Can you also check that you do not have your toe brakes assigned in MSFS (are you using an empty MSFS profile for your rudder?) or in SPAD.next. I can see the left brake movement in the log you attached, but not the right brake. Did you activate the right brake? If so, it seems that it is not assigned. The left brake logging shows some movement, and it looks like this axis needs reversing, which you need to do in the calibration tab (that you cannot see, for some reason...). I can also see in your log files that your USB devices were scanned again soon after the initial scan: Not sure what provoked this scan - did you open the FSUIPC UI? I see that you have set the DirectAxesToCalibs ini option in your [General] section. Do you need this set? And if so (if your devices are writing to the offsets for calibration), then you will need this set to All for toe brake calibration: So, try with removing that ini parameter, if not needed, or set to All. John

The timestamp is the first number of the log line. What was the last line logged when the error you see was displayed? Knowing the offset that is giving this problem may help the developer of the AflAgent client program determine what the issue is - did you contact the developer of this program? The last offset read (from the log you posted) indicates thet your 3rd party client was trying to read offset 6FFF. This offset is in an area (6F00-6FFF) that is reserved for XPUIPC use (i.e. for X-Plane), to avoid clashes, and is not actually used in FSUIPC7. Are you sure the client you are using is working with FSUIPC, and is not XUIPC specific? Also, did you exit MSFS/FSUIPC, or did FSUIPC close as it thinks that MSFS has closed? Your log indicates that FSUIPC7 exited very soon after the read request to that XUIPC offset: Are you using Windows 11? If so, please also add the following to the [General] section of your FSUIPC7.ini file: DisableMSFSMonitor=Enum John

What was the previous version that you were using? There were very few changes between this and the previous version, and nothing in the area in which you have issues. Do you have the same issue in P3Dv4.x and P3Dv5.x (your install log indicates that you have both)? The FSUIPC6.ini file you posted is also empty - no assignments whatsoever. I can see that you have also installed FSUIPC6 under your Documents folder. There seem to be issues these days installing under a Windows protected folder, such as Documents or Program Files. Can you please install in a different location (e.g. C:\FSUIPC6) and try again. First manually run the FSUIPC6 uninstaller, either from your installation folder or using the windows app management panel. Then install into a different location, moving any files you need to keep (such as your .key and .ini) to the new location. Then try again and report back. Thanks, John

Not sure what you mean by 'interface' in this context. What did you use in FSX? Is the 'interface' not the same? John

Hi Bruno, Not sure. You can try: 1. Activating logging for events and open the logging console. Change the ranges in the UI and see what events are logged. If so, try using them. 2. If that doesn't work, try listing lvars (using the provided control or the provided log lvars.lua script) to see if any look applicable. Again, try changing the range in the UI to see if any applicable-looking lvars change when you change the range. If so, you can try assigning to those lvars (using a macro or lua script). 3. If there are no events/controls or lvars, you can try with mouse macros. John

I always recommend that you try before you buy - you should initially have tried with the trial license, available at the top of this forum. Depends. Some people find MobiFlight easier to use. You can also use the MobiFlight WASM events via FSUIPC using event files. They are included in your EventFiles sub-folder. Instructions on how to use can be found in other posts on this forum - I will create a README.txt (when I get time!) and include this information at some point. Otherwise, you can use the MobiFlight hubhop preset list (see https://hubhop.mobiflight.com/#/list) to see what the preset is doing, and then use that to determine what assignments to use in FSUIPC. For the FLC, the MobiFlight preset for this is WT_CJ4_AP_FLC_PRESSED, which, looking at that preset's implementation, uses the hvar H:WT_CJ4_AP_FLC_PRESSED, so to use/assign to this you would first need to add that hvar to a hvar file for the CJ4 (to make it known to FSUIPC), and then add it to a macro and assign to that macro. See the Advanced User guide for details. There is also the preset WT_CJ4_FLC_ON, using the lvar L:WT_CJ4_FLC_ON which can be used to determine the state of the FLC (read-only). To engage the speed, the MF preset WT_CJ4_AP_SPEED_PRESSED uses the (read/write) lvar L:XMLVAR_AirSpeedIsInMach to switch between IAS/mach. You will see the control that you assigned to that button. To determine what is happening, you need to activate the AP button in the UI to see what is logged, and try to mimic that in your assignments. Unfortunately, this only helps if the aircraft is using standard MSFS events (i.e. those known to SimConnect/FSUIPC) and doesn't help if the functionality is operated using lvars and/or hvars (and maybe events). But that MF preset list is a great source of information on how to control such functionality. You are in the correct sub-forum, the FSUIPC7/MSFS sub-forum. Not sure what you want to delete, but maybe because your posts were not approved yet as you are a new forum member. Should be ok now. John