John Dowson

It should contain 0, but as that comment indicates this is not always the case. FSUIPC only stores the value in the offset as received from the NAV SIGNAL:1 simulator variable.

It comes from the simulator variable NAV SIGNAL:1. As the offset status document says: Maybe best to just ignore this value when no VOR. John

That log shows nothing...I need to see the complete log file. Compress/zip it. But I don't want to see this until you have removed the FSUIPC calibration.... This doesn't make sense...you are sending the controls direct to MSFS (i.e. you have assigned using Send to FS as normal axis and not Send direct to FSUIPC calibration). But you do then have the throttle calibrated in FSUIPC (in your general calibration section) so the controls are going to MSFS, then coming back to FSUIPC and being masked (i.e. not applied in MSFS), then calibrated and sent back to MSFS. You cannot assign with Send direct to FSUIPC calibration with aircraft using the *_EX1 controls. What you need to do (and this is now the third time I have said this...) is to remove FSUIPC's calibration in your DC6 profile. To do this. load the aircraft, go into FSUIPC's calibration tab and check the Profile specific checkbox. Then Reset the calibration of the throttle on page 1 of the calibration tab, and then go to page 3 of the calibration tab and Reset the calibration of the 4 individual throttles. This will remove FSUIPC calibration. If you need to reverse your throttle axes, use FSUIPC's axes scaling feature with a value of -1 (i.e. add ,*-1 to the axes assignment lines in your FSUIPC7.ini - see section Additional parameters to scale input axis values of the Advanced user guide for more details.). Did you see this: There are known issues with calibration, but if you set this up correctly you should be fine. PMDG provided me with a license for the MSFS 737 so that I can help with this, but I don'y have the DC-6. Otherwise, if it works better for you, assign your throttles for the DC-6 in MSFS, and make sure that you don't have them assigned OR calibrated in FSUIPC7. John

Hi Emile, the update in 7.3.17 was only to give the initial 'lvars ready' callback when the lvars are first loaded, which is now delayed until the initial values are received. When new lvars are found, the current lvar list is dropped and the update lvars are given a default value of 0. I can look into locking read-access to lvars on an update until the new values are received. In the mean-time, you can prevent the automatic scanning and updating of the list of available lvars by setting the following parameter in your FSUIPC_WASM.ini: LvarScanFrequency=0 Note that it is better to do this in the FSUIPC_WASM.ini under your AppData folder, not the one under the WASM Community folder, as this would get overwritten on updates - see the Advanced User guide for details on the locations of this ini file. John

Your ini file shows that you do not have any profile-specific calibration for the DC6, and so the general calibration section is applied. As I said in my previous post, please make the DC6 calibration profile-specific, and then remove (i.e. reset) the calibration settings for throttles 1-4. As I don't have the DC6, I am not sure how to calibrate that - does it come with any in-aircraft calibration settings? If so, you should use that. The log file you attached is of no use as you did not activate logging for axes controls as advised. If works ok without FSUIPC, this implies that you have also assigned your throttle in MSFS. You should only assign in one place - if you are assigning your throttles in MSFS, remove the assignments in FSUIPC, as well as the calibration. Your general calibration for throttle2 is also rather strange: You should correct that. Well, if you have the AFE running then this can also affect the throttle and throttle position. But again, as your DC-6 throttle is being calibrated in FSUIPC, this may be the same issue. Remove the throttle calibration for the DC-6 - but make sure that you make the DC-6 calibration profile-specific first or this will affect other aircraft that use this. Also see https://forum.pmdg.com/forum/main-forum/general-discussion-news-and-announcements/127235-msfs-dc-6-throttle-position-and-automatic-flight-engineer John Later: your Throttle4 calibration in your Superconny profile is also rather strange:

Please try logging the offsets using FSUIPC's offset logging facilities (Log -> Offsets) to check what they actually hold. Also check that you have them enabled in your FSUIPC7.ini with the following line under the [General] section: PMDG737offsets=Auto Also check for the following line in your FSUIPC7.log file: 65985 PMDG 737 offsets enabled If that is all correct then it is an issue in your code - please use Paul Henty's sub-forum of using his dll client for .Net: https://forum.simflight.com/forum/167-fsuipc-client-dll-for-net/ John

Sounds like you have calibrated in FSUIPC, or have a general calibration section that is being applied to the DC6. If you are using fsuipc profiles for the DC6, which you should be, go into the calibration tab of the Axis assignment dialog box and chexk the Profile-specific box (if not already checked), and then reset or re-calibrate your throttles there. If you still get the same issue, please show me/attach your FSUIPC7.ini and an FSUIPC7.log file, generated with logging for Axes controls activated and showing your issue, i.e. load rthe aircraft, and move the throttles through its full range and back again, and then exit FSUIPC7 before attaching your files. John

In the current released version, when lvars are received they are given a default value of 0 and then the actual value is received a short time layer, < 1s. In the latest beta, I have delayed the sending of the lvars by 1 second and so this should hopefully resolve this issue. Please try the latest beta, available here: If you get the same issue then please let me know - I have other ideas that can prevent this in the next official release, but was hoping that the delay introduced in this version should prevent this. John

What has your issue got to do with the topic you posted in - FSUIPC7 and MSFS Steam no connection with vAMSYS? Please do not hijack unrelated topics - start a new one if you cannot find a relevant topic. I have no idea what your issue is - please explain this better. Your log file just shows that FSUIPC7 exited after 13 seconds as MSFS was no longer available - it had either crashed or exited. MSFS asks this question if it had crashed in start-up the last time it was ran. No connection was established with FSUIPC as FSUIPC exited after 13seconds due to an MSFS crash. I cannot help with MSFS crashes - see the Asobo forums for this. John

Ok, thanks for the update. If I remember correctly, there have always been some issues with a plane being loaded from a default flight, but this was mainly reported from using more complex add-on aircraft, You could try switching aircraft after the default flight is loaded, and then switching back to the preferred one - I think this was the recommended solution as I remember, or switching to the preferred aircraft after a default flight is loaded with a different aircraft. But use whatever method works best for you! Cheers, John

Done.

👍

I see you have already posted there - wait for Andrew to reply, but I think support for the VRinsight CDU2 (and CDU3) panels was only added in LINDA 3.3.5 which is no longer compatible with 32-bit sims and FSUIPC4/5 - see https://www.avsim.com/forums/topic/573578-linda-335-p3dv5fsuipc6-compatible-5-jun-2022/ John

I am sorry but I cannot help you if you are using LINDA- you need LINDAsupport: https://www.avsim.com/forums/forum/429-linda-support/ John

Hi Ken, so it seems that the only thing not working correctly is the AP altitude hold. This is set with the write to offset 07D4, and only occurs in two places in your log: This is why the altitude is being held at 2800, not at 2000 as the panel shows, so it looks like it is out of sync. Rather than just switching alt hold on/off, maybe try changing the value to see if it then syncs correctly with the FS (turn off, change value, turn on). However, note that the comment on 07D4 (in the FSUIPC7 Offset Status document) says this: Autopilot constrained altitude value (limited by Flight Plan and flight profile as in SID), as metres*65536. Also see offset 0x0798 for target altitude value So maybe this value is being constrained by the flight plan? You can try logging both offsets 07D4 and 0798 using FSUIPC's offset logging facility (Log->Offsets, log as U32 and check Display to - Normal log file) to see what they are holding, although you will need to divide the logged value by 65536 to get the displayed value in meters. This would show you what the target value and constrained value is as held by the FS, and not what the radio panel is displaying - but hopefully at least one should match! But there certainly doesn't seem to be any issues with FSUIPC. Maybe fsRadioPanel should be using the target altitude offset and not the constrained one, but I am not sure. I am by no means an expert in AP systems - you would be better of asking about this on the avsim forums, or using the fsRadioPanel support. For the vertical speed, this is using offset 07F2 which has the following comment: Autopilot vertical speed value, as ft/min: Write reported as working but only after sending an AP VS SET control (only once) No AP VS SET control is being sent, so maybe this could be why this isn't working, and would (probably) need an update to fsRadioPanel to fix. However, as the target altitude is set at 2800 (and not 2000), which is basically the altitude you are flying at, the VS will be ignored anyway as you are at the target altitude - according to the FS, not the display panel. John

That is just how MSFS / Asobo document functions that are not working or fully reliable. There will be no elsewhere....it is up to Asobo to fix this. John

It is in the drop-down list of controls for button/key assignments when you Select for FS control. As stated in many posts on this issue, FSUIPC just calls the provided SimConnect SDK function to save a flight and it is this that is taking the time - there is nothing I can do about this. Note also that the SimConnect_FlightSave function is still documented as: NOTE: The current status of this function is NO ERROR, NO RESPONSE. which implies that it is still not 100% reliable. So I would recommend not to purchase FSUIPC7 if you only want to use it for this feature. John

Please attach your FSUIPC4.log file, not screenshots. This is as expected, as you are using an unregistered version and don't have any assignments in FSUIPC. However, if the G key is assigned in FSX, you should see the event (with Event (non-axis controls) activated) once processed by FSX. This seems strange, but does seem to be related to your default scenario. Try deleting that and saving a new scenario and make that the default, to see if this resolves the problem. John

Well, its not finally solved - this is just an interim fix that removes the request of simvars from the new fuel system. I will look into a proper fix so that these simvars are requested only when the new fuel system is actually being used.... John

Can you please also attach your FSUIPC7.ini file (although your panel isn't assigned in FSUIPC). Also please disable logging for Axes Controls - you only need Event logging activated, and the axes events are just noise in the log file for this issue. Keep IPC Write logging activated, as it looks like the FsPanelServer is writing to offsets to control things. I will check the offsets that it is using to see if these are writeable and working in MSFS, but a cleaner log file (without axes logging) would help. I will look into this further tomorrow. John

I really can't see how a key assignment can work at some locations and not others - this just doesn't make sense. I cannot really advise as I don't have this aircraft, although other posts indicate that landing gear assignments work for this aircraft, e.g. see You can also use FSUIPC's logging facilities to see what events are being sent - activate logging for Events (non-axis controls) and open the logging console, and see what, if any, events are logged when you retract the landing gear using the VC. Then see if you get the same event with your key assignment (you can also activate logging for Buttons & Keys). John

Those offsets are maintained based upon the AI traffic data received from MSFS via SimConnected. I suspect that MSFS isn't providing the traffic information for traffic injected by FSLTL for some reason. You can log AI traffic data (what FSUIPC is seeing) by using a Log->Custom value of x10000 or x50000 (for all AI data). John

You should NOT manually update the [LuaFiles] section. This section is maintained by FSUIPC and is the list of the lua files in your installation folder, or in the folder specified by the LuaPath ini parameter (which goes under [LuaFiles]). All your lua files must be in the same folder, not under sub-folders, or they will not be recognised by FSUIPC. They will, however, be auto-started, but they should really not be in a sub-folder. The log file you attached is incomplete (i.e. FSUIPC was still running) - please always exit FSUIPC before attaching logs. You are using a very old version of FSUIPC7 - 7.3.10. The latest and only supported version is 7.3.17 - please update and try again. There was a fix for this issue in the 7.3.11 update: John

I don't know how FsRadioPanel is using FSUIPC, so it is difficult to advise. You can try activating logging for Events as well as Buttons & Keys, open the logging console window (Log -> Open Console) and see what events/controls are being sent. You can also attach your FSUIPC7.log (generated with that logging enabled) and FSUIPC7.ini files here and I can take a look. Have you tried with various aircraft? Does this apply to all aircraft or only with specific ones? John

No - a purchased license is the same as the trial license, except that it doesn't expire. A short pause when saving a flight is common, especially when using complex aircraft. There are now many reports about this - see Check that the flight-save folder is excluded from any anti-virus scanning - this can improve the time taken to save the flight. John