Trim Stops Responding - Vendor Querying FSUIPC

[craig_read]

Hi,

Firstly this query has come as a result of a support ticket with another vendor (PMDG).  The crux is;

Info; FSUIPC Version 6.0.10, Prepar3D.exe version = 5.1.8.26742, PMDG 747-400 QOTSII fully updated.

After several hours of operation the 747 trim only responds to increase trim commands.  However it's not quite that simple.  On the VC if commanding trim down you will see the trim switches move on the VC yoke with the command, as they do with the increase trim command.  The only difference is trim setting only actually changes with increase trim.  In addition within the sim there are "Alt Trim" buttons in the VC, if these are used in this situation trim can be increased or decreased.  I added a keyboard command (whilst not removing the FSUIPC assigned trim control) to trim up and down.  The same behaviour was observed, trim would only increase but trim switches responded to both up and down trim commands.

Note this only happens after several hours (in the order of 10 hours or so).  During pre-flight trim behaves totally normally with the controls working perfectly.

PMDG are querying FSUIPC as a potential root cause.  They have recommended that I disable FSUIPC completely to carry out a test.  Before I do this, I am here to ask if this behaviour has been seen before and is there something silly I am doing wrong?  I have attached my configuration file to review, perhaps I've done something stupid there and just don't realise it.

I had a look in the FAQ but didn't see anything obvious and didn't see anything obvious from a search either, again I might have missed something there too.

Thanks in advance.

Craig

FSUIPC6 - Copy.ini

[John Dowson]

4 minutes ago, craig_read said:

Note this only happens after several hours (in the order of 10 hours or so)

If it only occurs after 10 hours or so, its certainly not due to anything in your ini file!

There is a related post where the sim stops responding to all controls when using PMDG but after 7 hours:

 

and also a post in the LM forums on this: https://www.prepar3d.com/forum/viewtopic.php?f=6312&t=139856&hilit=freeze+after+7+hours&start=15

Although this issue occurs with FSUIPC running, it has also been reported without FSUIPC running but with other SimConnect clients.

It therefore seems to be a SimConnect issue and not related to FSUIPC.

[spokes2112]

@John Dowson,

Maybe this will help, I am talking FSX here but it still may apply.
When I am doing some serious gauge programming and I need to test it I use "Reload User Aircraft". Each time this happens, Simconnect considers this a reconnect. After about 20 of these reloads Simconnect dies completely, never to work again until the sim is restarted. During these test runs I have no other things using simconnect, WX, traffic etc..
This anomaly has been confirmed over at FSDeveloper. ( Discussion, An improvement in the same thread)
I can only imagine that with PMDG, a weather program, possibly a traffic program, sode etc.. all connected, at some time Simconnect would have to restart due to something borking it.
After 7-10 hours multiple SC restarts seems plausible.                  

Roman

[John Dowson]

Hi Roman,

that's interesting and  could well be related. It also makes sense to what I have observed while developing FSUIPC7 for MSFS, when FSUIPC was reconnecting many times due to stalled data.

When you say simconnect dies completely, does this mean that there is not even an error reported in the SimConnect log file (when activated)? And presumably its not just the client requesting the connection that then fails, but all simconnect clients already connected?

FSUIPC can automatically re-connect if the data it is receiving is stalled for a configurable amount of time and a message is logged each time a connection is opened or closed, so it is easy to determine the number of connections FSUIPC7 has used. Not sure about other simconnect clients though, but the simconnect log would be the place to determine the total number of clients and number of connections made by each.

Another strange thing about these reports though  is  that different users  are reporting different symptoms/failures. Some users also report loss of controls in the FS (include mouse operations!), others loss of all flight controls, and some (like this post) just a failure in certain areas.

But I think anyone experiencing such issues after a long period should certainly look into this as a possible cause. It might be worth (following the advice in that link you posted) to initially adjust the maximum number of SimConnect clients (MaxClients) to a lower number, to see if the failure can be forced earlier. If thats the case, then it could then be increased to 255.

Thanks,

John