John Dowson

And one more test, with your original FSUIPC6.ini, could you add the following to the [General] section: Debug=Please LogExtras=x1000 and generate another log file where you move the axes assigned to the trim controls with the assignments window open, then exit. The log file could be quite large and so may need zipping before attaching. John

Hi, it maybe better if another blind pilot and FSUIPC user could assist you with this - maybe @Ron Kolesar or @Jason Fayre? The Set buttons define the minimum axes value, the null/dead range, and the maximum axis value. However, this can depend on the axis being calibrated, and with throttle calibration, it depends if you are calibrating with a reverse range or not - controlled by the checkbox No Reverse Zone (top left in the calibration tab, only available when calibrating separate throttles per engine). When calibrating with a reverse zone, the first set button calibrates maximum reverse (minimum axis value), the 2nd set button the idle range (click twice to set the range, first click will be the end of reverse/start of idle range, 2nd click the end of idle range), and the third the maximum axis/thrust value. When calibrating with No reverse Zone set/checked, you only calibrate the minimum and maximum axis/thrust values. By flying and checking the axis is working as expected. This depends on the aircraft you are flying, and if you have calibrated with a reverse zone or not. If calibrated with a reverse zone, then the idle range is calibrated using the second Set button. You can also post/attach your FSUIPC6.ini and FSUIPC6.log files here if you like, and I can take a look at your assignments/calibration and see if that is ok with the aircraft that you are using. Cheers, John

ok - good luck! Regards, John

You need to adjust the ButtonRepeat ini parameter - see the Advanced User guide, page 16. The default value for this is: ButtonRepeat=20,10 This will give a half-second delay between the initial button press and the first repeated button press (as explained in the documentation). If you want no such delay, change this to ButtonRepeat=20,0 Note that this will affect all button repeats, not just for trim. Cheers, John

No. Different versions of FSUIPC support different flight simulators, and each version requires its own license. For FSX, you used FSUIPC4. For MSFS2020, you will need FSUIPC7, which requires a new/different license. Before purchasing a license for FSUIPC7, you can try it using the trial license which is available in a sticky post at the top of this sub-forum. John

Hi Ed, Ok, thanks - this is want I wanted to confirm. In FSUIPC, the rudder trim was assigned to axis U, the aileron trim to axis V, and the elevator trim previously assigned to axis S. What are the corresponding axis letters for these axes in windows controllers and Spad.next? What do you mean by ' select the P-51 MIL profile'? You should not need to do this - profiles are automatically loaded based on the current aircraft name, and if you go to the axis assignment tab you should see the profile already loaded. It is only in the Button and key press assignment tabs where you have the ability to switch between profile and general assignments, as the general assignments for buttons and key presses are used when you have a profile, unless overridden in that profile. Do you see the same behavior when using another profile,, e.g. when using the aircraft A2A North American P-51D CIV? Could you also perform a test when you run with a default ini and see if these axes are recognised - just temporarily rename your FSUIPC6.ini file (e.g. to FSUIPC6.ini.unused) and run P3D/FSUIPC, and see if the axes you were using for the trim controls are recognised then. Can you also run a test without running Spad.next, just to confirm that is not causing this issue. John

Yes, I believe this is just a visualization issue that has been around since msfs was released. See this post about the issue on the MSFS/Asobo forums: https://forums.flightsimulator.com/t/movement-of-on-screen-yoke-does-not-match-real-controller/418391/18 Regards, John P.S. The same issue was also reported in FSX - see https://www.flightsim.com/vbfs/showthread.php?263439-The-movements-of-the-saitek-yoke-aren´t-truely-representated-in-fsx

What are those screenshots supposed to show? I can only see windows for the WASM test client and WideClient. Are you even running FSUIPC7? Have you installed it? Have you installed the WASM module? WideClient is usually ran in a client PC, not on the same PC as the FS. You run FSUIPC7 on the same PC as the FS, and WideClient on any client machines that you want to use with FSUIPC clients. So, please confirm that you have installed FSUIPC7 and that it is running. By default, once installed, it should start automatically with MSFS - you should see an FSUIPC7 splash-screen and then it will sit in your system tray. If you don't see the splash screen when MSFS is started, try starting FSUIPC7 manually (i.e. double-click the FSUIPC7.exe in windows explorer). If you problem is with FSUIPC7 not auto-starting with MSFS, please see the following: If there are issues running FSUIPC7 (e.g. you get an error when trying to run it) then your VC++ redistributables probably need updating - please see the README.txt file provided in the FSUIPC7 zip file you downloaded. Any further issues, please show me your InstallFSUIPC7.log file and your FSUIPC7.log file (if available) together with a detailed description of what you have tried and what the issue is - no screenshots please. John

Hi Daniel, As I previously indicated, the PFC driver is waiting for the ready-to-fly offset flag to change before the avionics are activated. The driver does not react to sim events, only offset changes. I don't think the polling frequency is an issue, it is the offset values themselves. This is why I need to see those offsets logged. If those offsets (or simvars associated to those offsets) are not being used by the Fenix, it is just a matter of determining what is being used (simvar or lvar) and then adding that to a spare/free FSUPC offset and then spoofing the value of the original offset (which is monitored by the PFC driver) to the value of the new offset. But I really don't think it is worth looking at this further if the OP is not prepared to supply the information required to resolve this for him. Thanks for your input, regards, John

I deleted one of your posts as you had just copied and pasted my previous comment. What is too complex? I gave simple instructions - what do you not understand? Have you even tried? You will be waiting for a long time... Controlling wither of these aircraft is a lot more complex than using standard/default aircraft. You will have to use lvars/hvars/custom controls and presets for almost everything, so you really need to familiarise yourself with how to use these if using such aircraft. Having said that, I don't think there is much difference between the control of these aircraft. I only have the 737-700, and there are only presets available for the 737-700 on the MF HubHop preset list (https://hubhop.mobiflight.com/presets/), but other users have said that most controls (custom controls and presets) are the same for both aircraft, although some differences have been reported. Not sure what you mean here, but the specific PMDG offsets are available for the 737-700, and I believe these also work for the 737-800. There is a document included in the FSUIPC7 documentation for the PMDG-specific offsets, so please see that. There are also some User Contributions on how to use the SDK, so check the User Contributions sub-forum (as well as maybe the FAQ sub-forum). John

I presume you are referring to @savery999's response - I would think he is using MobiFlight as he is referring to the 'More Options' checkbox for Substring from/to which you have checked in the image you posted. So, try unchecking that - and also try logging the FSUIPC offsets as I have advised, as this will confirm that the offsets are being populated correctly. John

Hi John, Ok. I know nothing about Delphi or Lazarus. This SDK was provided by Pelle F. S. Liljendal (pelle@liljendal.dk) over 20 years ago....you could try emailing him for support, but I think you would be better of using one of the more modern SDKs, Yes, I think that is a better choice, if you are familiar with C:# / .Net. Cheers, John

Hi Ed, I'm sorry but it is still not clear to me...could you re-read what I have said in my previous post and answer the specific questions and try what I have advised, i.e. you again say: Here you say 'elevator, rudder and aileron trim do not appear in the Type of action required' but what does show, if anything, in the joystick id/letter and axis letter boxes? Does anything register there, and if so, and it is not the correct axis, have you trued clicking the Ignore Axis button (not the Rescan button) and then trying again? Again, if a different axis is showing, click the Ignore Axis button and try again, not the Rescan button. Please do this and tell me what joystick id and axis letter you see, and it is not the expected one click the Ignore Axis button and try again. This indicates that the rudder trim and aileron trim ARE assigned, and you should see these (eventually) in the axis assignment tab. You will not see the Elevator trim as the latest ini you posted shows no assignments for this. You need to get this axis recognised again in the axis assignment panel (again, click Ignore Axis until you see this, NOT Rescan) and re-assign this. So, please take another look using the Ignore Axis button and not the Rescan button, and tell me what letters you see in the joystick and axis boxes. John

First, you posted in the User Contributions sub-forum where it explicitly states NOT for support requests. Did you not see this? This is happening a lot and I do not understand why - can you explain and let me know what I can do to stop this? As for your issue, you obviously have both FSUIPC5 and FSUIPC6 installed, which is very strange. Usually FSUIPC5 is detected and uninstalled when you install FSUIPC6, unless you previously converted your FSUIPC5 installation to use the add-on.xml method, in which case you need to manually remove it. Check your Documents\Prepar3D v4 Add-ons folder and see what is there - if there is an FSUIPC5 folder then remove it. Also check your Modules folder, if that exists then FSUIPC5 should be installed there. Otherwise, please show me your InstallFSUIPC6.log file together with any FSUIPC5.log and/or FSUIPC6.log files that are generated. John

But this doesn't make sense...if you have DirectAxesToCalibs set, then values written to the offsets will go through FSUIPC calibration, and so you must calibrate. From the FSUIPC Advance User guide: If you don't want calibration, maybe try removing that ini parameter. Otherwise, has this always been an issue, or is this a new issue since the SU10 release? I ask as there are various issues with calibration since SU10. If the issue persists, could you add logging for offsets 0x0BB2 and 0x0BB6 (using FSUIPC's offset logging facilities), activate logging for Axes Controls and Extras and produce a log file showing your issue and attach that (zip if large) as well as your FSUIPC7.ini file. Thanks and regards, John

Can you please post a full log. Also, what version of FSUIPC are you currently running? A full log would tell me this....if not using the latest version, 7.3.11, please update and try again... From the log extract you posted, FSUIPC can get a simconnect connection but the WAPI interface cannot, which is strange. Multiple WASM clients shouldn't be an issue, but I will check this again in SU10 and get back to you. I also see LINDA running (or being killed) and LRM as well as vPilot. Could you also try running the WASM test client when you get this issue, both when it occurs with FSUIPC and other programs, and see if that can connect or not when you get this issue with your other programs, I have attached this for your convenience. John WASMClient.exe

Hmm...even stranger.... But what is registered, if anything? If nothing is registered, why click the Rescan button? If anything IS registered, what? And if another axes IS registered, have you tried clicking the Ignore Axis button and trying again? And repeat until the axis is recognised...or not, as the case may be...please try this until the axis is recognised or you see no joystick letter or axis letter recognised. That would confirm that the axis/axes are not being seen. It is difficult for me to know this without you doing this and reporting back. And you say there 'is no recognition of the controller at all' - but I thought the other axes assigned to that controller were functioning ok: 'You had asked if the other axes (i.e. PropPitch and Throttle) on the DTA device are recognized and they are' . So, if hey are recognised and working, so is the device. Sorry to be so pedantic but your issue is very strange and you need to be very clear otherwise it gets confusing.... Maybe you could take a short video of what you see, which may help clarify things... Possibly - there are various APIs to access HID devices. You say that these are also not recognised by P3D. and FSUIPC recognises the device, and was previously ok (for 5 years) but there are now problems with specific axes/pots on the device (the ones assigned to trim), not the device itself (other axes are working, no?), so the problem is not that straightforward as device recognition. Or at least this is what it seams... I will let you know how to do this if/when necessary - for now, please just clarify the above. Cheers, John

I have moved your post to the main support forum so Pete has visibility, as he still supports this utility.

John, not Peter. Pete retired several years ago. Sorry, but I have no idea what this means. What is Lazarus? What are 'FPC Files'? What SDK/programming language are you using? FYI, the most used and supported client library would be Paul Henty's ,Net client API (see https://forum.simflight.com/forum/167-fsuipc-client-dll-for-net/).

Sorry, one more question: But what do you see registered in the axis assignment tab when you do this? Do you see the correct JoyLetter and axis letter registered and not the in/out numbers changing? Or do you see a different joy letter or axis letter registered? If that is the case, click Ignore Axis and try again. I would like to know if the device and axis letters are recognised or not in the axes assignment tab. Thanks, John

Hi Ed, I will look at those files in detail and get back to you. However, I first want to understand some changes compared to your previous files. The latest ini you posted does not have anything assigned to elevator trim. whereas previously you had this assigned: Latest ini: Previous ini: Have you manually removed this assignment? I will investigate further first, but it may be a good idea to disconnect the two DTA Rotary Encoder devices, reboot, clean the registry (back-up first), reboot and then reconnect. But first I would like more information from the HidScanner program - you need to keep it running to log changes of the trim rotaries...or not, as the case may be. I know this utility can do this but not sure how at the moment - I will get back to you.... John Later: sorry, I was mistaken - the utility does not log axes/button changes, only device connections

First, did you check that this lvar is working for you by using the Add-ibs->WASM->Set Lvar... menu item, as suggested? If not, first do that. This will confirm that you have the WASM installed and WAPI enabled so that you can use the lvar facilities. Also see what he maximum value makes sense for this lvar (maybe 5?) I'm sorry, but I am rather busy and do not have time to provide screenshots for this, especially when it is well documented and there are also many other support requests explaining this. Once you have confirmed the lvar is working, you need to add it to a FSUIPC offset. This is explained in the Advanced user guide, You need to create a new section in your FSUIPC7.ini as follows: [LvarOffsets] 1=L:A320_Neo_MFD_Range=UB0xA000 Alternatively, and better, if you are using Profiles you should add this in a profile section instead, i.e. [LvarOffsets.xxx] 1=L:A320_Neo_MFD_Range=UB0xA000 where xxx is your profile name. That will add the lvar L:A320_Neo_MFD_Range to offset 0xA000 as an unsigned byte. You can then assign to the offset control, using Offset UByte Increment for the increment button and Offset UByte Decrement for the decrement control, giving the offset as 0xA000. For the decrement control parameter, you want to decrease by 1 with a limit of 0, so the parameter would be 0x00000001, and for the increment control, you need to determine what the maximum value is (test by setting the lvar, as advised), but assuming this is 5, then the parameter for the decrement control would be 0x00050001. John

The lvar A320_Neo_MFD_Range seems to work, so you could use that....

That control won't work for the A320 Neo - it uses offset 0x0E04 which is not available in MSFS. I need to update the documentation on these additional controls as many no longer work with MSFS. I am not sure if it is possible to control this in the Asobo A320 Neo. You could try activating logging for Events, open the logging console, and operate the Efis ND map increase/decrease controls in the virtual cockpit to see if anything is logged. If so, you can assign to that. Otherwise, check to see if setting the following lvars has any affect: A32NX_EFIS_R_ND_RANGE and A32NX_EFIS_L_ND_RANGE. Initially try changing the value of those lvars using the Add-ons->WASM->Set Lvar... menu option. If they work, then you can create your own presets to use those lvars and assign to those, or add the lvars to FSUIPC offsets (as UB) and control by assigning to increase/decrease the value if the lvar using the offset controls. I can help you with either of these options if required, but first check if those lvars are working (i.e. you can update/write to them and that has the desired affect). Note that there are many functions that are not possible to control when using the Asobo A320. You may be better off switching to the FBW A320 which has many more systems implemented for external control. Take a look at the MobiFlight HubHop site (https://hubhop.mobiflight.com/presets/) to see what presets are available for control of this aircraft. John NB. I can update those lvars ok but it doesn't look like they have any affect...but please try yourself...

The offsets are holding the correct data as far as I can tell - this is what I see: and when I change the FLT or LAND ALT: John