John Dowson

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

Does it run ok when you click yes/Si? If you continue to get that message each time you start FSX, please see John

I think LINDA is your easiest option, but if you don't want to use LINDA then you will have to write your own lua scripts to handle your VRInsight MCP. As I don't have this device, I cannot help you with this. I have already referenced some posts by other users who have written lua scripts for this device - try using them as a starting point and updating the controls used to the ones needed for the aircraft you are using. If you need help with a specific control, I can assist with that. John

First, you posted in the Announcements sub-forum where it explicitly states NOT for support requests. I have moved your post to the correct forum for FSUIPC7 support requests. But events are for controlling not reading, and the PMDG offsets are read-only. If you are trying to read those offsets and they do not contain the information as advertised, then there is not much that can be done at the moment as the PMDG SDK has still not been published. You can check what the offsets are holding by using FSUIPC's offset logging functionality, available from Log->Offsets.... Try logging those offsets (as type AsciiZ) - this will yell you if those offsets are holding the correct data or not. If so, then your issue will be with MobiFlight and/or your configuration. If not. there is not much that can be done until PMDG publish the SDK. I will also check those offsets in the next few days and get back to you. John

Many aircraft, especially add-ons, can continually emit such events (different for each aircraft) - these are just noise. You can ignore these by using the DontLogThese ini parameter, best used in your [Profile.xxx] section (where xxx is the name of the profile). See the Advanced User guide for details. Also check that you are using an empty profile in MSFS for you controllers in MSFS. You can mix-and-match assignments between MSFS and FSUIPC if you wish, but best to start with an empty profile in MSFS if assigning in FSUIPC.

Thanks. I'll take a look at the log in detail when I get time to see if I can do anything about the phantom xbox controller.

As I have said several times, I do not support LINDA. Use the LINDA support forum: https://www.avsim.com/forums/forum/429-linda-support/ John

You should not need to do that unless you are running MSFS with admin privileges. And if not running as admin implies your FSUIPC7.ini file (where your profiles are saved) cannot be updated then this usually means that you have installed in a windows-protected folder, such as under Documents. You should not install FSUIPC7 in such folders, so if you have you should re-install and choose another location. John

The content of all offsets is documented in the offset status document - for 0x3124: Ok, thanks. Looks like that is a payware/subscription service, so I can't help with that. You need to contact their support to see why it isn't connecting I'm afraid as there is nothing more I can do or suggest. FSUIPC is functioning as expected. If you do get a response and a solution, please re-post here. John

If using LINDA, then you need to use LINDA support. I cannot help if using LINDA. As I keep telling you, standard controls do not work for many add-on aircraft (and even some default aircraft). For example, for the hdg in the FBWA320, the HubHob site shows these presets (amongst others): HDG Increase, HDG Decrease. These are using the FBWA320 custom controls: (>K:A32NX.FCU_HDG_INC) (>K:A32NX.FCU_HDG_DEC) However, there is already a LINDA module for the FBW A320 in MSFS - see https://www.avsim.com/forums/topic/599979-a32nx-linda-module-msfs/ I presume the LINDA module for this aircraft will be using the correct controls.... John

No. A preset is a label that identifies a calculator code string. You assign to a preset and when that preset is called, the corresponding calculator code is executed. I have mentioned this several times now and provided you with a link to the HubHop preset list (it is also mentioned in many places in the documentation), Uf you want to control aircraft in MSFS, you should familiarise yourself with presets. Look at the WASM section of the Advanced user guide, and the MF HubHop site. If you are using LINDA, you are better off with support from LINDA. I do not support LIINDA. Have you asked there? Again, if you are using LINDA, please use their support channel. If this is assigned in FSUIPC not using LINDA, disable LINDA and show me your FSUIPC files showing the configuration and the error.

Before I look at this in detail, could you clean your FSYUPC6.ini fil please. You have multiple sections for these when there should be only one: [General], [WideServer], [GPSout], [GPSout2], [AutoSave]. Also, I suggest that you clean-up your profiles to use substrings, so change to and to and similar for your other profiles For the profile you were using (P-51 MIL), you also have the same axis control assigned to multiple axes, e.g. 2=BZ,256,D,3,0,0,0 -{ DIRECT: Rudder }- 3=BR,256,D,3,0,0,0 -{ DIRECT: Rudder }- 19=JR,256,D,3,0,0,0 -{ DIRECT: Rudder }- 5=SY,256,D,2,0,0,0 -{ DIRECT: Elevator }- 6=SR,256,D,2,0,0,0 -{ DIRECT: Elevator }- Its generally not a goof idea to assign multiple axes to the same axis control as they can interfere, especially when on the same controller. Do you mean these assignments: So you don't see anything when you move those axes (DR, DU, DV)? If you see another axis instead, just hit the Ignore button and try again. Otherwise, please clean your ini as suggested and show me the updated ini and an FSUIPC6.log file, this time with LINDA disabled (temporarily), logging for Axes controls enabled, load your aircraft and move one of the unrecognised axes through its full range, then exit. John

Understood. But if its working with FSX, I don't see why it won't work with MSFS. The main difference between the two, for control/assignment purposes, is that many aircraft in MSFS, particularly add-ons, don't use the standard controls, and any custom controls used by aircraft in FSX will be different in MSFS. It should be just a matter of updating the controls you used in FSX to whatever works for the aircraft you are using un MSFS, whether it custom controls, lvars, hvars or presets. The basic plumbing should be the same - except maybe if previously using any 32-bit drivers you would need to switch to 64-bit, but hopefully that is not the case. Many folks are having difficulties controlling MSFS aircraft, especially the more complex add-ons. You should really be looking to use the available presets for such aircraft, and update your FSX scripts to use those.