John Dowson

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

I have just updated to the latest version, 3.0.42, and the SDK has now been published. Looks like there have been no further changes in the SDK, so the current PMDG offset document should be valid. I will check those offsets later today. John

Since the release of SU10, it is no longer possible to use FSUIPC's calibration facilities if not assigning with 'Send direct to FSUIPC Calibration', so when assigning using 'Send to FS as normal axis' you can no longer use FSUIPC's calibration facilities. I have raised this with Asobo but am still awaiting a reply to see what has changed in SU10 and if anthything can be done about this. The problem with the FBW A320 when assigning using 'Direct to FSUIPC Calibration' is that the throttle axis used with this option is not recognised. You therefore cannot use this and so you must assign using 'Send to FS as normal axis', as you were previously using, but you will have no calibration. You can use FSUIPC's scaling functionality on the axis (which includes reversing, if needed), but further calibration is not possible. However, you can use the calibration facilities provided by the FBW A320 itself, available from the flypad. This will create a ThrottleCondiguration.ini file - someone posted one of these for use with FSUIPC that you can use as a starting point in this post: Also, for throttle configuration via the flypad, see the video posted in this post: John

What have you tried? I don't see anything assigned to control the parking brake in the ini file you posted... First, I suggest that you update the aircraft name in your profile to catch more liveries - change to The easiest way to control the parking brake on the PMDG 737 is to use the available presets (see https://hubhop.mobiflight.com/presets/) : In FSUIPC7, select the 'Select for Preset' checkbox and you can assign to the inputs PMDG_B737-7_PARKING_BRAKE_ON and PMDG_B737-7_PARKING_BRAKE_OFF. For further details on how to use the MobiFlight presets, please see the WASM section in the Advanced User guide. John PMDG_NG3_SDK.h

Only the email address you used for registration - you can remove that if you like (near the top). Yes, if the aircraft name with that livery is not a substring match to the aircraft names listed under the [Profile.xxx] (where xxx is the profile name) section of your FSUIPC7.ini. You can add each aircraft name with livery as you use them, but better to edit the aircraft names in the profile section so that the string matches the aircraft regardless if the livery used, Please see the User manual section on profiles. John

These are functions provided by FSUIPC - just look at the Logging tab and it should be obvious...otherwise consult the User guide. Again, see the Logging tab, and yes the log messages are displayed in real-time - when you click a button/switch in the VC, and event is generated and FSUIPC picks this up and logs it, assuming logging is activated for that type of event. Correct - it is far easier to have the logging console open, which just shows the contents of the FSUIPC.log file, and note the events in real-time rather than looking at the log in an editor later. It really isn't complicated and certainly not worth making a video of this. Just open FSUIPC, selecting the logging tab and check the options you require (i,e, Events (non-axis controls) and Send to console window). Please take a look at this and consult the FSUIPC4 User Guide. I don't understand why you are not doing this before posting these questions.... John

You posted a continuation log - please always post a full log file for support, i.e. never use the New Log function if generating a log for support purposes. I really don't understand how the rudder and aileron trim can be seen in the calibration tab but not in the assignments tab. It is strange also that SPAD,next recognises the trim axes but not P3D or FSUIPC. Are the other axes on this device (DTA Rotary Encoder) recognised, i.e. PropPitch and Throttle: ? Are you using any specific drivers or software with this device, or are you using the default windows drivers? Can you download and try the HiDScanner program (available from the Download Links -> Useful Additional Programs section of this forum), run that and see if that recognises the rotaries you have assigned to the trim controls. Also try connecting it to a different USB hub, to see if that helps - and check you have power management disabled on all your hubs - windows has a tendency to reset this on updates. Finally, you could try disconnecting the device, uninstalling any specific drivers (if installed), cleaning the registry entries for the device, reboot and then reconnect to see if that helps. Something must have changed to cause this, and I suspect either a registry issue or maybe a hardware fault somewhere... John

Yes, they should. Where have you installed FSUIPC? If you have installed under your windows Documents folder, or under any other windows-protected folder such as Profram Files, then please re-install into a different nin-windows protected folder and try again - you can copy across your FSUIPC7.ini and FSUIPC7.key files (together with any *.lua, *.mcro or *.dll fies that you may use) to the new location. Otherwise, please show me your FSUIPC7.ini and FSUIPC7.log files. Yes, you can....the calibration panel should show the calibration being used, whether it be profile-specific or not. No. As I said, they are independent. FSUIPC knows nothing about your MSFS assignments/calibration, and MSFS knows nothing about your FSUIPC assignments/calibration. You should only assign/calibrate any given axis in one place - either MSFS or FSUIPC, not both. No, You can only calibrate in FSUIPC if assigned in FSUIPC with 'Send Direct to FSUIPC Calibration) (since SU10), and if you have assigned in FSUIPC then the axis should not be assigned in MSFS. Also, as you are using FSUIPC7, this post should be in the FSUIPC7 support sub-forum. I will move it to the correct location. John