John Dowson

Yes - it was clear in the title but I didn't realise that you were using the beta in my first reply, sorry about that. I don't understand why this affects some SimConnect applications and not others. it may be related to specific SimConnect functions - FSUIPC uses a lot more of the API than many other programs, such as the SimcarWatcher. But this is an MSFS issue - lets hope they fix thus un the next beta, or at least before the SU9 official release. Thanks for reporting this. I don't use the beta but I monitor issues that could affect FSUIPC7 in release, such as this one. Thanks for bringing this to my attention. John

This is for a different issue and is not related to the CTDs with the latest MSFS SU9 beta (which I don't have). See my previous comment. John

Ok, thanks for providing your fix. So it seems that the current beta does not like simconnect connection requests when its in the main menu. Hopefully they will fix this before release, if not I will look into updating FSUIPC7 then to handle this. Unfortunately I don't have the resources to enroll in the beta program as I need to be on the official release version for support issues - unless there is an easy way to switch between the two versions? John

Please don't report any issues with MSFS beta releases - they will be ignored. I have enough trouble keeping up with the official releases... This is also a known issue with the current beta and should be reported in the Asobo forums: https://forums.flightsimulator.com/t/spad-next-and-fsuipc-7-seem-to-be-causing-ctds/508349 John Later: also see this thread about CTDs with the latest beta, which also contains a work-around:

You don't need to update WideFS/WideClient when updating FSUIPC7. I also need to see your WideServer.log file, and also maybe your WideClient.ini... However, a few things to check: - have you set the servername or ip address in your WideClient.ini? If not, please do that (as well as the protocol). See the WideFS documentation - are both your computers in the same windows Workgroup? They need to be in the same workgroup to be able to connect - check your firewalls on both computers. You can disable them both first to check, and if it connects without the firewalls running you need to add exceptions to the firewalls to enable the connection John

Try not to embed your reply in the quoted text as its not that easier to read... No need to wait before clicking "Ready-to-fly". The scan delay parameter is not linked to this. If its never found, it doesn't exist. Maybe it is only created once the AP has been turned on? You can try turning th AP on and then re-scanning to see if it is found then. Otherwise, maybe the maximum number of lvars limit has been exceeded? How many lvars do you see? FSUIPC7 will only read up to a maximum of 2044 lvars. John

Understood, but you don't need lua to add lvars to offsets, just a section in your FSUIPC7.ini file. It should be quite straight forward... The options are not available until you have an aircraft loaded and ready to fly (i.e. not when MSFS is in the main menu). John

First, your FSUIOC version is out of date. Please download and install the latest version , v7.3.2 - only the latest version is supported. It is always a good idea to check that you are using the latest version before requesting support. This is reported as you still have assignments to those missing devices: Its not a problem, but if you want to correct this then remove all those assignments to these missing devices. John

To determine if the AP is set in the FBW A320 (dev version), you should use the lvars L:A32NX_AUTOPILOT_1_ACTIVE and L:A32NX_AUTOPILOT_2_ACTIVE. If you want them in offsets, you can add to a free (for general use) offset area using the lvars-to-offsets functionality. Check the Advanced User guide for details on how to achieve this. John

The WAPI (WASM API) provides a createLvar function, and if you are using Paul Henty's dll for .NET, that may have access to that function via C#. However, if this is an lvar that is provided by the aircraft, you should not create it yourself. Try an determine how long it takes for the lvar you want to use to be created after aircraft load, and then set the LvarScanDelay parameter accordingly. Alternatively, you can always call the Reload function (at any time), which will rescan for all available lvars (and hvars) when called. John

Not a silly question, but more one for Asobo.... As far as I know, hvars are 'html variables', which can only be triggered/activated. Like events, but events are associated with the model, hvars with the interface/UI. But events can also take a parameter. As far as I am aware, there is no value associated with a hvar. John

I have to say this after every MSFS release...if MSFS crashes, it is an MSFS issue and should be reported to Asobo, not here. Lots if people seem to be having issues with the latest release, some using FSUIPC7, others using SPAD.next or other simconnect clients. From the CTD on starting the sim thread on the Asobo forums: The Topic Author selected a solution that apparently has nothing to do with FSUIPC. I recommend those of you who are still having trouble and seem to have isolated to FSUIPC to participate in this thread instead. SPAD. NeXt seems to be causing CTDs CTDs I suggest anyone experiencing this issue follow that advice and report to Asobo using that thread. AI data has known to cause issues on previous updates. those experiencing this issue could also try with the following added to the [General] section of your FSUIPC7.ini file: ProvideAIdata=No I am running with this and have had no issues. I will also try with this removed when i get a chance. John

The README.txt file is in the zip file you downloaded. It is not installed into your FSUIPC documents folder.

👍😎

Probably just the aircraft, and most (if not all) aircraft probably don't use strings for lvars. All lvars are actually treated internally as 64-bits/ 8-byte values. The STR functions are just provided for convenience. But note that your else clause to read the lvar using ipc.readLvarSTR will never be reached. Even if the lvar was actually holding a string value, the ipc.readLvar would still read the value and return the string interpreted as a floating point number. You really need to know that the lvar is holding a string value before using that function. There are no values associated with hvars - you can only activate them. Nope. Lvars should be documented with the aircraft and provide this sort of information, but very few aircraft (if any...) provide such documentation. Not that i know of, except by trying to set / change the value and then reading to see if it contains the value you set. But, if the value is not set it could also possibly be due to the current aircraft state. John

Sorry, by manually editing the calibration entry I mean that you open your FSUIPC6.ini file (or the ini file for whatever version you are using) in an editor, find that line, change it and save. Do this either with FSUIPC not running, or if running then keep the Axis assignments tab open when you do this and click to reload your assignments once updated. John

Nope - both your install log and your EXE.xml look fine. Are you sure FSUIPC7 isn't running - did you check your system tray for it? If it definitely isn't running, have you tried starting it manually? If so, does it run ok? If it isn't running via auto-start, and it runs ok manually, you could try changing the order of your 3 auto-start items in the EXE.xml to see if that makes a difference. If not, I really have no idea why MSFS isn't starting FSUIPC7 or following the directions in the EXE.xml. If nothing else works, you can go back to the old method of starting FSUIPC7 from the MSFS.bat / desktop icon (installed by FSUIPC). To do this, open the MSFS.bat file in your FSUIPC7 installation folder and find the following lines: and remove the comments for the delay and the start command, i.e. change to John

If your knob/rotary is assigned to 'Direct to FSUIPC calibration', then you can achieve this by manually editing the calibration entry. For example, this is my trim calibration setting: ElevatorTrim=-16383,0,0,16254/16 To only use 25% of the range, you would need to multiply the high/low limits by 4, so use: ElevatorTrim=-65532,0,0,65016/16 John

Then why don't you assign to this custom control? I cannot see any assignment to this control in your ini. I don't know, that is up to you to work out - I do not have any PMDG aircraft. If you follow the instructions in the guide in the FAQ section to derive the correct control number and parameter, you should be ok. But you should try operating the parking brake in the UI with appropriate logging activate, which should then (hopefully) show you the control and parameter to use. The log you attached is a continuation log. Please always attach full log files, never continuation log files. If it is too large to attach, just zip it. Keep the log as short as possible by only testing what you need to test and nothing else - in this case, you only need to set and release the parking brake, nothing else. Also, it seems that you do not have event logging activated (although its difficult to tell as its a continuation log...) which is needed. The aircraft cockpit UI. The general method of determining what control to use to assign to something (key/button/switch/axis) for a function is to activate appropriate logging and then use that function in the cockpit/UI (i.e. using the mouse) and see what is logged. You keep the logging console window open by selecting 'Send to console window' in FSUIPC's logging tab. This then shows you the .log file contents and updates in real time. John

If using C#, you should seriously consider using Paul Henty's dll for .Net, which is built on top of the FSUIPC SDK. I am sure there are plenty of examples, and the support/download forum is here: https://forum.simflight.com/forum/167-fsuipc-client-dll-for-net/ John

ok. John

When you list lvars via the WASM menu option, an automatic reload is first performed, which will reload all lvars and hvars. The problem will be that the lvar was not discovered (and hence not available) when the lvar list was sent from the WASM to FSUIPC7. By default, the lvar scan is performed 5 seconds after aircraft load has completed. but it can take a minute or longer for lvars to become available in more complex aircraft. You can change this by setting the LvarScanDelay ini parameterin the WASM - see the Advanced User guide for details. I use a value of 45sm which although doesn't give me all the lvars for some of the more complex airliners (e.g. FBW A320), it gives me all those that I use. Alternatively, you can switch from using the lua lvar functions to using calculator code to set the lvars. Setting an lvar via calculator code does not require the lvar to be know to FSUIPC. Also, rather than lua, you can use a calculator code preset and assign to that directly. There is probably already a (MobuFlight) preset available for the lights - check the MobiFlight preset list (https://hubhop.mobiflight.com/). John

You can also use P2ATC on a second computer with FSUIPC7 installed on the 2nd computer, without the need for WideClient. See FSUIPC7 must be registered (i.e. licensed) to do this. A trial license is available in a sticky post at the top of this forum if you would like to try it. John

You still have two sections for [LuaFiles] & [WideServer] - please remove one of each so that each section name appears only once. Ok, but I do not see an assignment to that control - you still seem to be using 65752 (PARKING_BRAKES). Change to use the PMDG custom control, and make sure that you are using the correct parameter for the custom control. And as I said, please also attach your FSUIPC6.log file with appropriate logging enabled. Also try activating the Parking Brakes from the UI to see what is logged when you do that (if you keep the logging console open you should see what is logged when you set/release the parking brakes). John

First, the latest version of FSUIPC6 is 6.1.8 - you are using 6.1.7, so please update - only the latest version is supported. Second, but nothing to do with your issue, you have multiple ini sections for [Sounds], [WideServer], [GPSout], [GPSout2], [AutoSave], [Buttons] and [Axes]. Please remove the duplicated sections, leaving just one of each. Please also turn on AutoAssignLetters in your [JoyNames] section, i.e. AutoAssignLetters=Yes This will prevent possible issues caused if your joystick ids change, and make it easier to recover settings if the devices GUIDs change. And is there any reason why you have turned ini file annotations off? I know you have added your own comments, but you can still do thus with annotations turned on. The ini file is a lot easier for me to understand with the FSUIPC annotations. As for your actual issue, I'm sorry but I don't really understand what you are saying... What does this mean? What "shows"? Why are you giving me event ids? The control/event names are far easier to understand: 65752 = PARKING_BRAKES 70325 = ? what us this - a custom control? The only assignment I see to any of this controls is: 523=P3,0,C65752,536870912 ; -PARK BRAKE LEVER- You don't need a parameter P3D for the Parking Brakes control - it is a toggle control so no parameter needed. You also don't say which aircraft you are using. If its the PMDG 737, check you are using the correct custom control and the correct parameter. Please see this guide: Also, as PMDG has its own custom controls which are not valid for any other aircraft, that aircraft should really have its own profile (i.e. take out the (Freja Viking) Winglets 737 to a separate profile). Also, you should use substrings for profile matching to catch all variants, so change your [Profile.B737] section to the following: (N.B. that still includes the none-PMDG Boeing which should really have its own profile). If you are still having issues, can you please show me the updated ini, together with a log file generated showing your issue (i.e. with logging activated for Buttons & Keys as well as Events), together with a description of what you did and see. John