John Dowson

Hi Günter, This is an error from P2A. You need to contact their support - I cannot advise on other 3rd party products that use FSUIPC, sorry. John

FSUIPC6 runs as an embedded dll in the sim, and so the sim is always running/available in FSUIPC6 (as well as FSUIPC5, FSUIPC4, etc). FSUIPC7 is now an exe, and runs independently of the FS. However, this can cause issues if the sim is not running and you are using specific hardware/drivers that expect the sim to be available (or, at least, the offsets in FSUIPC populated when the sim becomes available). If using such devices, then you really need MSFS running.

Ok, but this has nothing to do with FSUIPC. Yes, there seem to be quite a few issues with the A320 Neo at the moment. There are currently many controls that work when assigned in MSFS, but are not working in external programs using SimConnect. It is a known issue and we are awaiting an SDK update to resolve these issues. Cheers, John

Ok, so you weren't using the GFdev64.dll on P3Dv5, so this makes more sense. I have no idea what the GFDevP3Dv4.exe is - does this work with MSFS, or is their an equivalent one for MSFS?

Yes, should be.

Fully up, with a slope value of -15 is more sensitive around the center point, and fully down with a slope value of +15 is less sensitive around the center point and more sensitive around the extremes. I'll post some pictures of the slope curves with the different values when I get a chance. Btw, which PFC driver are you using? If its the PFCcom one then you should calibrate in the driver UI and not assign/calibrate in FSUIPC.

Hi Hans, an interesting idea. It should really be the other way around, with FSUIPC7 starting automatically with MSFS, as it does for other FS versions. However, this will only be done once I've written the installer AND we know how to do this. I haven't seen how this can be achieved at the moment and am waiting for details on this from Asobo. There are also complications due to the different installation processes using Steam and MS Store. But I'll keep this in mind. Thanks for the suggestion. John

What do you mean by this? What 'task bar'? There is currently am issue with control loss due to a TransmitClientEvent failure that will be seen in the logs. If you have this in you logs, then this is already being investigated, and there is another topic covering this. And there is also this topic for control loss without this failure being noted: No solution at the moment as I'm still trying to determine if this is an MSFS issue or an FSUIPC7 one. Note also that someone previously reported this is a problem and it turned out to be an automatic co-pilot takeover that somehow got activated. Maybe worth checking for that as well. Otherwise, it would be helpful if you could determine if it is only the controls via FSUIPC7 that stop working, and if any assignments you have in MSFS are still functional.

Can you show me your FSUIPC7.ini file and I'll check the calibration. Not sure what this is or means! Ok. That would explain the RUDDER_SET events in your log.

Sorry, what does this mean?

I'll check further if its possible to set via events/controls - I think I checked this previously but it wasn't working, but I'll check again. If not working, I will report to Asobo on this issue.

Yes, its not updating the AUTOPILOT ALTITUDE LOCK VAR simulator variable on the AP_ALT_VAR_SET_ENGLISH event. I have reported to Asobo.

Offsets 0x05C4, 0x05C8, 0x05CC & 0x05D0 are no longer writeable. in MSFS, so for read only. Its not a bug unfortunately, but stated as read-only in the SDK documentation. The FUIPC7 offset status documentation documents these in red for writeable, i.e. not working.

But how was it working in P3Dv5? With LINDA and the GFDev64.dll? And you could see the devices buttons/switches in the FSUIPC assignments panel? Your log shows the device detected ok: I'm just wondering if LINDA is masking the input from that device somehow. Try temporarily disabling LINDA and see if the device is then visible in the assignments panels.

Please see John

I don't know - you should ask FSX Flight. However, only FSUIPC7 is compatible with MSFS. You should download and try it.

Do your button/switch assignments also stop working? What about any controls assigned in MSFS? If you don't have any axis assigned in MSFS, maybe try assigning one so you can test this when the problem occurs.

Ok, I thought it would, but unfortunately no idea why! Rather worrying.... John

Unfortunately not. I have reported many things, in the beta/third-party developers forums as well as via zendesk tickets, but am not getting much response to anything at the moment. I believe Asobo are aware of many issues with SimConnect and have various updates planned, so hopefully many of these will be addressed in these updates, but any concrete information is sorely lacking. The current SDK is still at version 0.5.1. Yes, that is/was are hope, but not sure if that's the case. Unfortunately I think they are currently more interested in xbox or "game" users rather than simmers, and the development of the SDK is a much lower priority.

So, of I understand you issue correctly, you are not seeing any errors in the FSUIPC log. When you say do you mean in the assignments/calibration window, or are you logging axis movements and seeing them there? I would be interested in seeing a log file produced when this occurs and you restart FSUIPC and get the same problem. And when you say: does this imply that, in other cases, the isue was only resolved by restarting MSFS? Other than that, I'm not sure what else I can advise at the moment. It may be worth activating SimConnect logs (as shown in the other thread) to see if SimConnect is still receiving/sending when this issue occurs.

Yes - do not load any flights using FSUIPC7 until Asobo have fixed this issue. And yes, Asobo is aware of this issue, and there isn't much that can be done about this at the moment. I am thinking of disabling the 'load' options for the time being, just to prevent people using this and then suffering the consequences....

You are using LINDA, so you need to contact LINDA support. I cannot help you with LINDA.

No idea. Why don't you ask them? They just said that they would report back once updated (as far as I can remember). Again, no idea. Such questions need to be addressed to Microsoft/Asobo. They have public forums for these type of queries now MSFS is released. Please see

Don't send a control on the button release. You can overload the button press to send both the Avionics set on and Avionics set off event/control when the button is pressed. You will need to manually edit the ini to achieve this. You then need to add an offset conditional check on offset 0x2E80, so that only the 'off' control (with parameter 0) is sent when the avionics are on, and the 'on' control (with parameter 1) is sent when the avionics are off. Offset conditions are explained in the Advanced user manual (for FSUIPC4/5/6).

If you read the initial post in the 'FSUIPC7 control problem' you will (hopefully) see that this is completely distinct from your issue, although you did also post your issue there (again, thread hijacking). The issue in that thread is that his controllers are no longer working, it is NOT a random disconnect issue. Its really not difficult. Search for an issue that is the same or very similar to yours. If one exists, use that thread. If not, create a new one. For your issue, please check your USB power management settings. If they are correct and you still have your issue, please start a new thread.