John Dowson

Its from the PMDG SDK via a Client Data Area - see the PMDG SDK documentation file PMDG_737_MSFS_SDK.pdf. John

From the PMDG SDK - se the document Offset Mapping for PMDG 737-700: 65D0 2 Signed short MCP_VertSpeed John

I do not provide access or support earlier versions - only the latest version is available and that is the only version supported. I can't see how there can be issues, except if they are using one of the 4 offsets that were populated from simvars in the new FuelSystem module which are no longer available, otherwise 7.3.18 corrects some issues with 7.3.17. Please see the history document for details of the changes (or the changes.txt file). What exactly are these issues?

Btw, if you are not using the latest version of FSUIPC7, 7.3,18, can you please update and try with that version. Earlier versions were could be logging hundreds of console messages (in the MSFS console) every second with aircraft not using MSFS's new Fuel System module. This can maybe cause some logging contention issues if something else is also logging a lot to the console. You could also take a look at the console messages to see if there is anything there relevant to this issue (you need to switch to Developer mode to access the console window). John

Strange that this only started in the last 2-3 weeks - what, if anything, changed in that period? Can you first check that you are using the latest FSUIPC7 release, 7.3.18. Also check that the buttons/switches you are using are not also assigned in MSFS. If you get the same issue, can you activate FSUIPC logging for Buttons & Keys and Events. Then generate two log files for me, one showing the issue when the flaps go full down/up, then reload the buttons and activate the flaps inc or dec again, and then exit. Then show/me attach the FSUIPC7.log and your FSUIPC7.ini. For the second test, use the same logging and use an aircraft without a profile, and then try and operate the flaps in the three ways mentioned - using yoke button, VC and keyboard. Again exit before attaching the log. I will take a look at your files tomorrow if I have time, but most likely it will be on Monday. John

Ok, thanks - I would be interested to know the cause of this.... Regards, John

It is reverse polish notation - see https://docs.flightsimulator.com/html/Additional_Information/Reverse_Polish_Notation.htm John

Yes, they should. Not sure what is causing this - can you check the Power Management settings on your usb hubs (using Device Manager) and make sure that Allow the computer to turn off this device is unchecked. This has been reported previously for FSUIPC7, and I added an extra ini paramater which when set will automatically perform an axis scan when a simconnect connection is established. I can look into adding this ini parameter to FSUIPC6 to see if that helps, but this will be sometime next week. John

You need to multiply by -1, so it would be: BSBonanzaMixtureAxis#-100 $Param 16384 - * 32768 / (>L:BKSQ_MixtureLeverPosition_1) John

No - FSUIPC7 is for MSFS2020 only. There are other versions for FSX (FSUIPC4) and P3Dv4 & 5 (FSUIPC6). John

If the response problem is with the Oi4FS/OC devices/driver, then I think that they should be the first point of contact for this issue - not having or even knowing anything about this software, I cannot really comment on this. And if there is no issue with FSUIPC7 itself, I cannot investigae/look into this issue. John

? Sorry, but it is not clear to me what your issue is with this description - can you please elaborate. For example, I do not know what "tap at the bottom" means. It would also help if you could attach your FSUIPC5/6.ini and FSUI{C5/6.log files, the latter generated with Axis controls logging enabled (if your issue is with axes assignments) and when you experience (and rectify) the issue. John

This would indicate an issue with the external apps, and you need to contact the developers of these apps. Your logs show no issues in FSUIPC, and you are not using the FSUIPC WASM module. I would suggest that you contact the developers of SimBitWorld about this issue, I cannot support 3rd-partt FSUIPC applications, If there is an issue in the SDK (which I doubt - this has been stable for many years), then they should contact me for support on any FSUIPC SDK issues. Sorry I cannot be of any more help. Your log files show no issues with FSUIPC. John

Thanks - I had forgotten about that! John

Wasn't my previous message clear on what to do: ? When I say "try with the default values", I just mean with these not specified in your ini file, as anything there will take presidence. No point in looking at your logs until you try this. John

Ok, but if that is controlling the display, then you need to see if that can be configured to show 3dps. Ok, but it can be quire complex, especially for non-programmers, to control the GF display via lua. There is an example script provided (in the lua examples zip in your FSUIPC documents folder), and there are probably other posts on using this library if you search the FSUIPC forums. u suspect that you don't need to the GFDisplay.exe. And you could also try asking in the Go Flight support forums, presuming they supply the GFDisplay.exe. Cheers, John

7.3.18 has been released - can you please update to the released version. I see you are using a VRI device. Your log shows FSUIPC is hanging when trying to close the DevCom threads for this device: However, the threads look like they have been forcibly terminated, so I am not sure why it isn't exiting correctly. Can you remove the following entries from the [General] section in your FSUIPC7.ini file (if they exist) and try with the default values (10ms) for these: ComReadLoopTime, ComWriteLoopTime. If you get the same issue, try reverting to the previous values by setting: ComReadLoopTime=20 ComWriteLoopTime=20 John

I have tested here now and haven't found any issues, Are you still experiencing these problems?

How are you driving the display? As far as I understand, you should be able to display any text up to the length the display can handle - usually 5 characters or digits. Take a look at the lua gfd library for handling GF displays in FSUIPC/lua. As I don't have any GF display devices, it is difficult for me to advise any further. John

Many people use this throttle with FSUIPC. Just download it (from FSUIPC7 v7.3.18) and try it - an trial license is available here: See the User manual and how to assign and calibrate, and make sure you have removed any assignments in MSFS - best to create a new empty profile for the device in MSFS, although you can gave some assignments in MSFS and others in FSUIPC if you like. If you have any issues, first check/search this forum for any possible solutions (most questions have been asked before!), but if you can't find anything relevant then post again and I can help. John

I don't think this is the case....from the PFC.DLL User guide: This seems to imply that 9600 is the rate that is needed. John

If its working except for the visuals, it may use a hvar (html variable type) - you would need to look at the xml code to see how it is defined. Its not possible to scan for hvars I'm afraid. Presume this aircraft is quite new as it doesn't appear in the MF HubHop preset list yet. Maybe worth checking and/or asking about this on the MF discord server if you can't find anything.

FYI, I have release FSUIPC 7.3.18 and WASM 1.0.2 and WAPI 1.0.2. No API changes in the WAPI. John

FYI, 7.3.18 just released - available from the usual locations. Finishing for the evening now (dogs need walking!). Any issues, I can help tomorrow. John

You shouldn't need to do this either...you either installed into a different folder or must have removed your FSUIPC7.key file manually. I hope you have not lost your settings, stored in your FSUIPC7.ini file. If you have changed installation locations, you can copy this file from its old location to the new one and everything should be restored. Btw, I have just released 7.3.18. You should update to this version now. John