John Dowson

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

Also, the offset I would like to see logged (initially) is the following: 3102 as U8 - ELECTRICAL MASTER BATTERY Maybe @Fragtality can check this? The avionics won't turn on unless this is set. I presume 0x3364 is set (otherwise FSUIPC wouldn't be working), and Daniel has already told us that offset 0x3103 (AVIONICS MASTER SWITCH) is always 1. If the ELECTRICAL MASTER BATTERY simvar isn't being used, is there an lvar that can be used instead? Thanks, John

@PSantosYou are using an old version of FSUIPC7, 7.3.6 - the latest and only supported version is 7.3.11. Please update. Also, I have said (and probably several times): Can you please do this when generating log files for support. There is also no monitoring of the requested offsets in your log file extracts. Did you check the button Display to Normal log file? If not, please do that - you must select a destination for the offset logging otherwise nothing will be logged. Do you see the PFC Control Connection Check dialog box? And do you have access to the PFC driver window? If so, please activate logging in the PFC driver for Log all decoded received data (under the Test tab), and also attach your PFCcom64.log and PFCcom64.ini files. I would also like to see a PFCcom64.log file and FSUIPC7.log file generated when using another aircraft where the avionics panel turns on as expected - just start the sim and load the aircraft and when the avionics stack has turned on, exit FSUIPC7 and show me the same files for this test, John

It looks like the PMDG SDK documentation for the 737-700 is wrong, and the Rotor Brake control is still being used. Please see John

I have checked this now with the latest/current PMDG 737-700 release (3.0.42) and the Rotor Brake control is still being used - I therefore suspect the documentation is wrong. You can see the various Rotor Brake events if you activate logging (in FSUIPC) for Events, open the logging console and activate some switches or rotaries in the VC. I have also tried assigning to several controls and everything I have tried is working as expected. The only issue I see is with the documentation. I will check the PMDG support forums and report this if it has not already been reported. For those getting the TransmitClientEvent event error with this aircraft, I need to see your assignments and log file (with appropriate logging activated) to look into this - no point in just posting the error (I need to see the context). Thanks, John

There is no point in just posting the error - please attach your FSUIPC7.ini file and a full FSUIPC7.log file containing that error, and generated with logging for Buttons & Keys as well as Events activated. John

I am not sure what you are referring to here.... I do not see any drop-down menus. Topics are always created in the forum you are looking at when you click the 'Start new topic' button. You just need to be in the correct forum (one without the text NOT for support request) which is either the main top-level forum (this one) or the specific FSUIPC7 sub-forum. Ok, glad its sorted. Cheers, John

Sorry, I think I misunderstood your question...you are asking if event.offset calls for the same offset will be queued? I don't think they will be, but it should be easy enough to test for this. John

Did you check your FSUIPC7.log file to see what it was logging for those offsets? Please do not post screenshots (unless requested) - I need to see your FSUIPC7.log and FSUIPC7.ini files, the former generated with the requested logging activated. This logging will tell you/me if there is a problem with FSUIPC receiving the PMDG data, or if it is a problem with your MobiFlight configuration. John

Hi Paul, ok, thanks for the info. I saw the SDK had been published (with some changed to the .h file but nothing that requires an FSUIPC update) but hadn't checked/noticed this. This is not only going to screw up peoples existing assignments to the Rotor Brake control, but also to any presets (MF or otherwise) that are also using the Rotor Brake control. Not sure why high custom event numbers no longer work either, unless higher than 4194304 (0x00400000) as that is the internal flag/value I use to mark preset controls, but that shouldn't be an issue as they start from THIRD_PARTY_EVENT_ID_MIN which is 0x11000 (69632). I will take a look at this tomorrow, or when I get the OPs log and ini files, as requested. John

No - you can have multiple event.offset calls on different offsets. if its on the same offset, I'm not sure of that is added or replaced without checking, but a simple test should reveal the answer to this. John

Hi Al, Any change in the offset value will trigger the event. However, there is a delta specified on request of the simvars for each offset, and so only changed values that differ by more than this delta value will be received. This delta value for offset 0x6050 (GPS WP BEARING) is 0.009. John

oh - can you also calibrate the trim rotaries in windows calibration, after you have removed the reg entries and reconnected - this will ensure FSUIPC is getting the full value range.

Nothing in those logs - did you check the Display to - Normal log file checkbox in the offset monitoring panel? Forgot to mention that (thought this would be obvious...) - please do that and try again. Also, PLEASE do NOT EVER use the Log->New Log menu option when generating log files for support, and always exit FSUIPC before attaching log files. I need to see one complete log file. Yes, sorry - you don't need to specify the Ox in that window, the values are assumed to be hex. John

No, sorry - you have to run P3D to use FSUIPC5/6. I mainly get support requests for FSUIPC7/MSFS these days and had switched to FSUIPC7 support mode - sorry about that. John

Yes, please disable LINDA when generating logs for me. Lets try cleaning the registry before the next test. First, take a backup of your current registry. Tun the windows Registry Editor application and take a registry backup (File -> Export...), remembering to select the All checkbox. Next, disconnect your two DTA Rotary Encoder devices, and then download and run (i.e. double-click it in windows explorer) the attached file: removeDTARotaryEncoders.reg Then reboot and re-connect your devices. Then start FSUIPC7 and see if the trim rotaries are recognised, i.e. the axis assignment box sees them or not (you don't need MSFS running to do this, or anything else) - you won't see the trim assignments, but this is not important at the moment, just want to see if the those axes are recognised. You can also attach the updated FSUIPC6.ini and FSUIPC6.log files after doing this and I will check them again. John

Yes, sorry about that. Yes, that is all correct - I was just clarifying that the aircraft/FS updates the simvars, not offsets, and it is FSUIPC that maintains the offsets based on these simvar changes. I believe it is just the ready-to-fly flag, but I will check this again. This is also my approach, which is why I have requested monitoring of those offsets. @PSantosSorry, UB should be U8, UW should be U16. I will correct my post. John

👍