John Dowson

How strange.... But it seems to have resolved itself....still no idea what caused this though, very puzzling... Anyway, glad is all now working - thats now one weird issue of my list! Regards, John

So that would be this one (from the SDK header): #define EVT_MCP_HDG_SET (THIRD_PARTY_EVENT_ID_MIN + 14504) // Sets new heading, commands the shortest turn Neither do I... There should be no changes between FSUIPC6 and FSUIPC7 when using custom controls, if supported by the aircraft, but maybe MSFS handles these differently to FSX/P3D. I will check this and report back (will be tomorrow now though at the earliest). Cheers, John

I am going to remove this option, due to difficulties confirming whether MSFS actually has the focus or not. I will still allow negative values (for backwards compatibility) but they will be treated the same as positive values.

This is not correct - all 3 axis were recognised, but the order was R, then U, then V - and according to your assignments, these are assigned to elevator (R), rudder (U) and aileron (V) - so that must have been the order you rotated them in: Not that important, just wanted the order so that I know what to look for...Maybe better to refer to the axis by its letter rather than the assignment (or both!) so we don't get confused...! Ok, so they are working and recognised in FSUIPC7....can you go back and try again in FSUIPC6 please. No need to attach logs, just see if the axes are recognised and if you see any movement... it gets even more puzzling if they are recognised in FSUIPC7 but not in FSUIPC6 as the code for device handling is the same. if this is the case, then there must be something else going on when you run FSUIPC6/P3D... John

Can you confirm that you did not see the device number and axis letter recognised in the assignments box when you did this test (i.e. they stayed blank), and that the in/out numbers didn't change? Your latest log shows the rudder trim axis (U) went from 0 -> 65535 -> 0, the aileron trim axis (V) the same, but no movement at all on the elevator trim (R). I would have expected the first two to have been recognised.... John P.S. Will keep using FSUIPC7 to investigate this, so you can reset your system back to its original state so that you can continue to use it, and any tests for this issue will no longer interfere with that system. You can also try assigning the trim axis/pots with SPAD.next...if you do, let me know how that goes, especially with the elevator trim...

Your installation now looks fine. Note that your ACARS program will not connect until you have an aircraft loaded and ready-to-fly - it will not connect when MSFS is still in the main menu system. You can check your FSUIPC7.log file to see if any errors are reported, but you probably need support from the ACARS client provider(s) if the client isn't connecting. You can also try searching this forum as such issues have been reported many times. John

👍

I've just looked into this a bit further...it is not possible to restore this functionality completely, due to the change from an embedded process to a separate application. When using a non-negative number (i.e. 0-100), a windows flag is set when instructing windows to play the sound with "Global Focus", and this is not set when a negative number is used, and so it is windows itself that controls whether you hear the sound or not, but the sound file is played regardless. What this means if that if you play a sound using a negative number, the sound file is still played and if you change the focus to/from the FS then the sound will be played/muted as you change the focus. Now that FSUIPC7 is a separate application, this is no longer possible. However, I could add a check on the existing focus, and if a negative number is used and the FS (or FSUIPC) does not have the focus, then I can just not play the sound file. The result would be similar but not identical, as it would be FSUIPC7 not playing the sound file, rather than windows playing the file and muting when the requested application does not have the focus. Do you think this is still useful and worth implementing, or should I just remove this option?

At the moment, yes - but really its a bug, a hangover from FSUIPC6 which is an embedded dll, so the FS has the focus when FSUIPC has the focus. I will take a look at this an either restore the correct functionality (i.e. only play the sound if the FS has the focus) or remove this option - I don't think it worth keeping if it only plays when FSUIPC7 has the focus. John

That is playing with a volume of 100 on sound device 0 - but only when the FS has the focus. I haven't checked this (i.e. using negative numbers)....maybe it only plays when FSUIPC7 has the focus? Can you check this? And does it work with sound.play("paxsign.wav",0,100) ?

If you had checked your log file, you would have seen this: 47 *** FSUIPC WASM module not detected - not adding WASM menu This is because the installer has detected that you are using a Steam installation, and has installed the WASM here: Installing FSUIPC7 WASM module in C:\Users\Adam Poincon\AppData\Roaming\Microsoft Flight Simulator\Packages\Community\. But FSUIPC7 is detecting an MS Store installation, and is checking for the WASM under C:\Users\Adam Poincon\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\Packages\Community Are you using a Steam or an MS Store installation? Why do you have a UserCfg.opt file in two locations: Steam: C:\Users\Adam Poincon\AppData\Roaming\Microsoft Flight Simulator\UserCfg.opt MS Store: C:\Users\Adam Poincon\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\UserCfg.opt ? Have you switched from Steam to MS Store (or vica versa)? If you have switched from Steam to MS Store, you should uninstall FSUIPC7 completely by running the uninstaller (or from the windows app management panel). Then remove/delete or rename the following file: C:\Users\Adam Poincon\AppData\Roaming\Microsoft Flight Simulator\UserCfg.opt (although I suspect this file is no longer present, which is why FSUIPC7 thinks you have an MS Store installation) Then re-install FSUIPC7 and try again. John

Yes. And the latest log shows you now have those offsets being monitored: That is the log of the initial state of the offsets, which shows them empty, which is normal. However, there are no other log entries, which indicate that no PMDG client data is being received. For comparison, this is what I see: i.e. the offsets being updated when the data is received from the aircraft. So, I am pretty syre that you have not enabled data broadcasts in the aircraft. I see you tried with the 737-800 - can you try the 737-700 and use thar instead as I don't have the 800 (although they should be near-enough the same). I don't think those paths are correct....as with your UserCfg.opt file, they should be under your user AppData folder - this doesn't change with your MSFS installation. Try activating data broadcasts in the following locations: C:\Users\bossq\AppData\Roaming\Microsoft Flight Simulator\Packages\pmdg-aircraft-737\work\737_Options.ini C:\Users\bossq\AppData\Roaming\Microsoft Flight Simulator\Packages\pmdg-aircraft-738\work\738_Options.ini AND check the name of your 738_Options.ini file - previously you posted two 737_Options.ini files and no 738_Options.ini file - is it badly named? If so, the broadcasts will not be enabled. So, in summary, your issue is with data broadcasts in the PMDG aircraft still not being enabled. That is a mobiflight error - I cannot support MobiFlight, you need MobiFligjy support. There should be no difference in behavior with FSUIPC if you start FSUIPC manually or if it is auto-started with MSFS. John

Hi Jason, your files show that you are using an unregistered version, so I presume you are sending these events by writing the control numbers to offsets, using MobiFlight or some other software. The controls you are trying to send have control numbers 70166, 70167, 70168, 70172, 70173 and 70174 - all with a parameter of 536870912 what are these controls? If they are custom control numbers, as used with the P3D version, then you need to change these to use the Rotor Brake control instead (control number 66587), with an appropriate parameter. See the link I posted earlier on how to calculate the parameter for the Rotor Brake control for control of the PMDG 737 in MSFS. Alternatively, you can use Event logging to log the event (usually Rotor Brake) and parameter used when the switch/rotary/button is operated in the VC, and then use that. John

No, sorry - you have to store the ref and use that to stop sounds playing. Even killing the lua will not stop the sounds playing... John

Ok, thanks, Then the batteries are always on - that should be ok... I think the next step is to compare the PFCcom64.log files generated for the Fenix with one for another aircraft where the avionics are working. As well as logging for Log all decoded received data checked, can you also check Log COM data sent. Comparing the two files should show any differences between the data being received and what is being sent to trigger the Avionics to come on.

That is the location (well, the Packages folder at that location) shown in the latest log file: Your UserCfg.opt file is still under C:\Users\bossq\AppData\Roaming\Microsoft Flight Simulator\ - this does not change, regardless of the installation location. Did you correct them? Are they in the correct location? If you activate event logging, you will see the events logged. However, I do not see those in the log file you posted, and event logging is also not activated in the ini you posted. However, your ini file shows that monitoring is activated for those offsets, but there is no logging on the file - are you sure that they are from the same folder/run? I cannot see how those cannot be logged when requested - do you see those offsets logged in the console window (shown in your screenshot)?

It is a stand-alone application and not a full installer, so no documentation. FSUIPC7 sits in your system tray when running - you can access the main window from there. Once the main window is open, you can access the functions through the menus. John

No - just set the logging (you can use the Log->Custom function and enter x1000), open the assignments panel and rotate axis through its full range, then exit and show me the log file. This will just let me know what movement FSUIPC sees on each axis - there was some movement before but difficult to tell with so much noise/other devices interfering. Let me know the order you rotated the 3 trim switches, and start them all at min, and rotate them to max and back to min again reasonably slowly (a second or so in each direction). Thanks, John

No, they are independent/distinct applications. Just create an FSUIPC7 folder somewhere, but the FSUIPC7.exe and FSUIPC7.key in the folder and run the exe, Yes, you don't need an FS to run FSUIPC7. You will get a warning/informational message when you open the axes assignment window, but thats it. No problem. Cheers, John P.S. Your simpit looks cool!

What path is wrong, and what is the correct path? The FS path is taken from your MSFS UserCfg.opt, which is located here: C:\Users\bossq\AppData\Roaming\Microsoft Flight Simulator\UserCfg.opt And the FLT path is just used for saving and loading flights and flight plans. BUT, this will have nothing to do with your issue. That just means they are enabled in FSUIPC, not in the PMDG aircraft. Looking at the 737_Options.ini you posted/attached (twice - why?), you do not have data broadcasts enabled in the aircraft. You have: whereas it should be That is probably your issue.... The log file you posted is also not complete - please always exit FSUIPC7 before attaching a log file. And it still doesn't contain the logging information requested. Your ini file shows that you have selected to send this logging information as a Debug string. Not sure why you selected this - you need to send to Normal log file. John

This is not true...the FSUIPC7.log file you posted was attached when FSUIPC7 was still running (there are no closing statements), and the FSUIPC7_prev.log is a continuation log: Also, please stop posting screenshots, they are of no use. And for the PFCcom64.log, please only activate logging that I suggest - turn the other logging off. I don't need to see your PFChid64.log file either. Can you try again, and this time just log offset 3102 as U8 (as I asked for in my last message), and show me one full FSUIPC7.log file, your PFCcom64.log file (with only logging for Log all decoded received data checked. Thanks, John

No! Sorry, I just realized that when I was taking the dogs for a walk... However, you can actually use that as the device handling is the same. You can use the attached license. Don't run P3d/FSUIPC6 though. John FSUIPC7.key

Try the same test with the following build - make sure you move each of the 3 axes through their full range (from min to max and back) with the assignments panel open. And let me know the order in which you tried them Thanks, John FSUIPC7.exe

I am not sure what you mean by this... There is no path to MSFS in FSUIPC, and the log is just that - a log file, There is no point in changing that. Note that the log file you posted is from 25th April 2022 and is for version 7.3.2, and the ini file you posted from version 7.3.11. Are they from different folders? Did you change the location of the MSFS Community folder? If so, maybe the WASM needs re-installing? Although the WASM isn't needed to access PMDG offsets. I really think you need to check things again at your end. Are you even sure you have enabled data broadcasts for the PMDG 737? As far as FSUIPC7 is concerned, I suggest that you uninstall it by running the uninstallFSUIPC7.exe that you will find in your FSUIPC7 installation folder. Once it has uninstalled, re-run the installer to re-install - you can choose the same/default folder (C:\FSUIPC7) and your settings (and registration, if registered) will be maintained. John

Hi Ed, I didn't think the registry cleaning would do much but it was worth a try. It is difficult to see what is happening in that log file - I am going to provide a special build for you with additional logging as well as restricting the current logging to the device which has this issue (with joyId 2 and letter D in your original ini). Once I have supplied this build, please perform the same test - and let me know the order in which you are trying the trim controls, and make sure that you just move each control through its full range just the once, i.e. from min axis value to max and then back to min. However, although I don't understand what has occurred at the moment, I can't see how this can be an issue with FSUIPC5 or FSUIPC6. As this was previously working, do you have any idea what could have changed? Were there any windows updates just before it stopped working? John