John Dowson

I don't have the fenix, but if you engage vnav by pressing the altitude button, you could try the preset FNX320_FCU_ALTITUDE_KNOB_PUSH. See https://hubhop.mobiflight.com/presets/?vendor=FenixSim&aircraft=A320 for a list of the available presets for the Fenix - all MobiFlight presets are available for assignment in FSUIPC. You can also see these by using the Find Preset button in the assignments panel, after checking Select for Preset:

What part? And what part don't you understand? In which panel? as I said, you cannot change this in the axis panel. In button & key assignments, you can assign a button to either a profile or not, and should be able to check/uncheck the profile-specific checkbox accordingly. If this is not clear, please provide more information - what arte you trying to do? Which panels are you using - axis, button or key assignments?

For PMDG aircraft, you can use the provided custom controls. See For the NG3, the custom controls are: #define EVT_MCP_VNAV_SWITCH (THIRD_PARTY_EVENT_ID_MIN + 386) #define EVT_MCP_LNAV_SWITCH (THIRD_PARTY_EVENT_ID_MIN + 397) You can also use FSUIPC's logging facilities to determine what is being used: set logging for Events, open the logging console and see what is logged when you press the switch in the virtual cockpit. This will be a custom control using the Rotor Brake control, which is an alternative method of using PMDG custom controls, also described here: (N.B. when logging events in many add-on aircraft you will see many events being continually logged - you should ignore such events using the DontLogThese ini parameter) For the Fenix, you can also use logging to determine what is being used. If no events are logged, try listing the available lvars (Add-ons ->WASM->List Lvars) to see if any look applicable.

There are a few things that could be improved in the script: 1. You only need to create the lvar once, do you should handle this if the script is being called multiple times. 2. If you create an lvar using ipc.creatLvar, you don't need to reload the WASM afterwards - this is done automatically. As for the timing issue, lvar values are, by default, updated and send out from the WASM at a frequency of 6Hz, so roughly every 166ms.Therefore a delay of 100ms is not going to be enough most of the time, although this depends on the timings. Taking into account the time needed to send and process the request, you would need a delay of 200ms to make sure the new value had been received. if you want faster updates, you can set the WASM ini parameter LvarUpdateFrequency to VisualFrame. if ipc.getLvarId("L:Lear_LDG_Weight") == nil then ipc.createLvar("L:Lear_LDG_Weight",10361) ipc.sleep(600) end ipc.execCalcCode(" (A:TOTAL WEIGHT, pounds) (>L:Lear_LDG_Weight) ") -- get current total weight ipc.sleep(200) ldg_wt = ipc.readLvar("L:Lear_LDG_Weight") ldg_wt = math.floor(ldg_wt + 0.5)

Thanks for this - I will move it to the User Contributions section. Also note that another way to use the mode switch to have different assignments to the same button/switch depending on the mode switch positiin is to use compound assignments. You need to manually edit the FSUIPC7.ini file to do this, and the method is documented in the Advanced User guide. However, this is only applicable to button (and key) assignments, not for axis assignments. John

Your license information is available in your SimMarket account. John

Yes, you need a radar.bmp file for any of this to work. This was provided by ActiveSky, but that functionality isnt available for MSFS. Once you have the radar.bmp file then sharing/displaying shouldnt be a problem. But I do not know how you can generate such a file with MSFS. Note I am on holiday now until September. John

👍

You just add it to your ini and it akways applies. But dont switch it off (i.e.set to yes), try setting it to Enum first. This will still monitor, but using a different method.

Just caught me in time... Currently lua is the only possible way to do this. I will look into allowing 2 parameters for events at some point, but I have a few more urgent things that I need to do before I can look into this. Note I am now on holiday until September, although I will be checking for support issues occasionally. John

Please also note that I am now on holiday until September, although I will check for support issues occasionally. I am now out-of-contact until Monday though. John

As with all other users who report this, your key validates just fine. I will pm you a key file and try this. Save the key file to your FSUIPC installation folder, then re-run the installer and validate the key by clicking the Register button at the end of the installation process, If it validates, then the only possible reason that you are unable to register is that you did not enter the details correctly. If it does not validate, and you have installed the required VC++ redistibutables, then it can only be your anti-virus software blocking the validation - please check that.. Can you PLEASE respond once you have done this. I would like to understand why so many people are having this issue so that I can update the documentation accordingly, but nobody is responding. John

Do NOT manually edit the [LuaFiles] section. This section is maintained by FSUIPC. Your script is never running, so the offset will not get updated. Before you write the axis value to an offset, check if you can use either offset 0x3416 / 0x3418. If you just want notification that the brakes are being used, you could also try the 'brake being used' flag in offset 0x32F9. So check these offsets first. If none of those offsets are working, then maybe consider using a lua script. If those offsets don't work and you want help with a lua script for this, it would help me if you could provide a log, with logging set as previously advised. Note that I am now on holiday until September, but I should have time to look at this again on Monday if you need help with a lua script (so please provide the log file before then). John

👍

You can do that but I wouldn't recommend it, especially if the app connects to MSFS or FSUIPC. The batch file will also be overwritten/replaced whenever you update FSUIPC7 as well, and you would lose any changes. FSUIPC provides facilities to start other programs (registered/licensed version only) - you should use that. These facilities provide options to delay the start of the program until MSFS has started or until an aircraft is ready to fly, can also close or kill the program when MSFS exits, as well as other options. See the section Programs: facilities to load and run additional programs on page 44 of the Advanced User guide. John

The log looks good! I think the lesson from this thread is that if you want to calibrate any axis in FSUIPC for the iFly 737, then you also need to have the axis assigned in FSUiPC using the send direct to FSUIPC calibration option, and not the send to FS as normal axis one. I consider this topic closed now (unless you have any more issues). You can remove the logging now, including removing the [Auto] section to start the lvar logging lua script. Regards, John

By "switching off", do you mean that FSUIPC exited? You log file shows that FSUIPC was running for just under 6 hours and then exited as MSFS was no longer running. If MSFS was still running, you can try setting the DisableMSFSMonitor ini parameter to Enum or Yes. From the Advanced User guide: John

Thats good news! I will check your logs tomorrow, but I would suspect it was the change in assigning the toe brakes using 'direct to FSUIPC calibration', instead of 'send to FS as normal axis'. I cant see how the other axes assigned in P3D could cause this, especially as it was working without the toe brake axes being calibrated in FSUIPC, and you only get the issue when the Toe brakes were calibrated. Some (complex) aircraft dont play well when using FSUIPCs axes calibration facilities when an axis is assigned in P3D or in FSUIPC using 'send to FS as normal axis'. For such axes, you should assign using 'send direct to FSUIPC calibration' and calibrate. This is also the better/preferred/recommended method anyway. The underlying issue is complex but due to conflicting priority levels used to trap and mask events in FSUIPC and the actual aircraft. John

Is FSUIPC7 running? Is it connected to MSFS? Check your FSUIPC7.log file... You can also try adding Init3308=13 to the [General] section of your FSUIPC7.ini file. This will pre-populate offset 0x3308 with the version number for MSFS2020 (13) which is needed by some add-ons. If using MSFS2024, set this to 14 - although some add-ons not yet updated for MSFS2024 may still require this to be 13. Your add-ons must also be running at the same privilege level as FSUIPC7, so check they are either all running with standard privileges or all with admin privileges. There are also many other posts on connection issues with VAMSYS - check those. And if you still have issues, when FSUIPC7 IS running and IS connected to MSFS, AND you have added the init3308 parameter to your ini file, then show me / attach your FSUIPC7.log file and I will take a look. John

To log the lvars, please save the attached script to your FSUIPC6 installation folder: logLvars.lua Then add the following to your FSUIPC6.ini file: Before take-off, please again rotate the autobrake switch through the settings so that I can see the values associated with each setting. You can also now remove the assignment to list the lvars as it is no longer needed. John Later: I have also now added logging for the lvars when the OnGround flag changes,

But you assigned them using 'Send to FS as normal axis'. When assigned this way, the calibration is going to work the same way as when the brakes are assigned in P3D, i.e. the brake events are sent to the FS, then picked-up by FSUIPC, calibrated and re-sent. As I previously said, you should try assigning using 'Send direct to FSUIPC calibration'. When assigned this way, the calibration is done before the events are sent to the sim. Sorry if this wasn't clear, but can you please try that. There are several lvars related to the brakes/auto-brakes that look interesting: Maybe worth monitoring some of these. You would need a lua script to do this, which I can provide. I'll try and does this later today. But it is clear that offset 0x2F80 isn't being used, so you can remove logging for that offset if you like. I think this is because of the extreme slope you have now combined with the initial null zone. Once you have changed the toe brake assignments to Send direct to FSUIPC calibration, re-calibrate your brakes, giving an appropriate slope - look at the ini/out values as you are doing this, where the out value will be the amount of braking applied ranging from -16384 as no brakes to +16384 as full brakes. I would suggest starting with a slope value of 9 or 10: 15 is pretty excessive and won't give any breaking until the pedals are nearly 25% depressed, and effective breaking a lot later, e.g. 25% breaks when 5/8ths pressed. You can also reduce the initial null zone on the toe brakes to your preference - its the min value of the toe brake calibration. I won't worry about that if momentary... Isn't this always the case? Does the disarm light come on before you start manually breaking? I can understand why it comes on when you manually start breaking, but not if before. Any manual breaking will/should disarm the autobraking. But, from your earlier logs, autobraking WAS initially working when calibrated in FSUIPC, but only partially and only for the first second or so after touchdown, and then it looked to be disarmed. Anyway, the logging of the lvars should hopefully show what is occurring in more detail. A log of when autobrake is working/calibration disabled would also be useful, with the additional lvar logging. I will provide the lvar logging lua script later and let you know how to use this. John

Ok. I have updated the script available in the first post in this topic to accommodate for both reversed brake and rudder axis when necessary, and provided instructions on how to do so. John

That would imply that the rudder axis is reversed. Look at the rudderChange function, and find this: Then add a line to reverse the rudder after that comment, i.e. You could also add a rudderAxisReversed variable and do this on an if...then conditional if you wish, as is done with brakeAxisReversed. John

You could also try adding a null zone around the toe brakes, so any small changes (e.g. when using the rudder) doesn't de-activate the autobrake. Try something like: [JoystickCalibration] LeftBrake=-15750,16383/8 RightBrake=-15750,16383/8

The problem seems to be this entry in the registry, which has the same GUID as your TCA Q-Eng 1&2 device: This seems to be a phantom xbox controller and I think is related to steam. Try ignoring that device, i.e. add IgnoreDevice=0x28DE,0x11FF to the [JoyNames] section of your FSUIPC7.ini file. I have added this for you in the ini attached below if you would like to download and try that. Note this is what I also advised earlier when you had the same issue (see above). John FSUIPC7.ini P.S. See this thread from this comment onwards on this issue: Basically it only seems to happen when FSUIPC7 is auto-started by MSFS and when a Steam installation is being used.