Jump to content
The simFlight Network Forums
YukonAV8

Testing version 3 RC2 - occasional double entry required

Recommended Posts

YukonAV8    0

First of all, thanks both to Pete for FSUIPC and to Paul for FSUIPCClient - awesome tools. So I downloaded the client RC2 and threw together a csharp program using VS 2017 to emulate the FMC CDU. No issues using Offset 0x5400 and FSUIPCConnection.Process to read the CDU and then parse it to a rich text box. Also, no issue using FSUIPCConnection.SendControlToFS(offset, leftmousebtn) for each of the buttons, but once in a while, I have to press the button twice to get it to take affect. No errors are being thrown. Is there something I can do to try to figure out when it takes multiple calls about 1 out of 8 times to get the control (in this case the FMC buttons) to work? In case it matters, I am running on a remote PC using WideClient. I tried to include a screen shot of the CDU but it limits to 20k. The PC I am connecting to is running Prepar3D V4.

Andy

 

cdu vs2017.PNG

Edited by YukonAV8
Sorry for multiple edits, trying to get it right

Share this post


Link to post
Share on other sites
Paul Henty    31

Hi Andy,

Have you tried running it on the same machine as FS? This will tell you if it's a problem with WideFS or not. You could also have a look at the WideServer and WideClient logs to see if there's anything there that would suggest the network connection is being overloaded.

If the same thing happens without WideFS being involved then I'll investigate further.

Paul

Share this post


Link to post
Share on other sites
YukonAV8    0

OK, good suggestion. I went ahead and deployed the app to the main simulation computer and did not start multi-channel. Also did not start the throttle driver, the cpflight module, sioc, the Arduino driver or any other module which could be interfering. I was seeing some similar behavior where I would send a button and get no action from the simulator but it did not happen as often, maybe once in 25 times. I am going to investigate further and try to see if I can find a pattern or way to reliably recreate the problem before wasting your time. Any other suggestions of what to look at are welcome.

The csharp code uses a timer to read the CDU once per second with a .Process("CDU") call. I made sure the CDU offset was only defined once and reads 1008 bytes at 0x5400. The handler for each of the buttons on the form is set to use a common routine which reads the 'tag' attribute of the button to get the relevant offset (i.e. 70178 for Init Ref) and then calls the .SendControltoFS with left mouse button as the second argument - nothing else is going on in the program.

I'm not sure polling the CDU every second is a great idea but I couldn't find any way to get a notification that the CDU display changed.

Thanks, Andy

 

Share this post


Link to post
Share on other sites
YukonAV8    0

I worked on this a while and found that if I set the timer faster and the CDU read happens twice a second instead of once a second, I lose a lot more keypresses/send to controls, so I am wondering whether under the covers somewhere inside the client code, it is timing out or encountering some error. CPU and Network are barely loaded, aircraft is sitting on the runway. Given this is a single treaded app, I wouldn't expect collisions and nothing else is interacting with FSUIPC right now. I am not getting any errors thrown or any log file entries. I also added a left mouse button up call after the left mouse button down call and that just made things worse. 

So for now, I just put the polling to 2 seconds and I guess I can live with that, but would still be good to understand why I am not getting a response. If I could detect an error, I could easily automate the retry. I also wouldn't rule out that this is actually a PMDG problem and the key press is getting through but the sim is not executing it for some reason.

Any other ideas, feel free to jump in. Meanwhile, I am going to move on to the Arduino interface stuff.

Thanks much, Andy

Share this post


Link to post
Share on other sites
Paul Henty    31

If you use the logging features in FSUIPC (maybe to log all IPC Writes) you will see when the controls (CDU button presses) are being received by FSUIPC.

When you get a dropped button push, if it shows up in the FSUIPC log then the sim has received the instruction from your application. This would indicate the problem is likely on the PMDG side.

If the dropped key presses are not shown in the FSUIPC logs then it's a problem with the DLL communicating with FSUIPC.

I think you'll need to do the logging on when your app is running locally as  opposed to running over WideFS.

Paul

 

Share this post


Link to post
Share on other sites
YukonAV8    0

Thanks for the suggestion.

OK, I turned on the IPC Write logging, then I set up a csharp form with a 'parking brake on' button and SendControltoFS, I deployed the program to the local computer. I pushed the button every two seconds and watched the log. Every 4 to 6 times, there was no entry in the log. All the other times, it created an entry for 3110 and 3114 as expected. The only odd thing, which didn't seem to correspond with the missing entries, but I will bring it up anyway in case it matters: most of the time the write to 3114 was logged prior to 3110, but once in a while the 3110 came first. I'm pretty sure the FSUIPC documentation says to always write 3114 first before 3110. I believe that happens under the covers of FSUIPC Client. Might just be the way logging works for simultaneous events if you are writing all 8 bytes at the same time, I suppose, since the simulator seemed to receive the command.

I may try writing directly to SimConnect next.

Andy

Share this post


Link to post
Share on other sites
Paul Henty    31
Quote

most of the time the write to 3114 was logged prior to 3110, but once in a while the 3110 came first

I don't like the sound of that.

I'll test it here and see if I can reproduce this. It could be related to your problem if the DLL is sending in the wrong order sometimes.

Paul

Share this post


Link to post
Share on other sites
Paul Henty    31

Yes, it's a bug in my DLL. The order of the offsets is being mixed up by a Dictionary. I'll fix it today and post a new version.

This is very likely what's causing your problem with your CDU presses.

Paul

Share this post


Link to post
Share on other sites
YukonAV8    0

YES! So that definitely fixed the issue with 3110 and 3114 sequencing and the parking brake test now runs 100% reliably. Thanks!

Relative to the CDU. If I turn off the CDU display read which runs on a timer at one second intervals and uses .process to read and then parse 1008 bytes from offset x5400, then the CDU button triggered key presses work every time (both locally and remotely). If I turn the timer on, I start to lose button presses (which use .SendControlToFS) every 5 to 10 times. (locally less often than remotely). (and no they do not show up in the FSUIPC log when they are lost). So there is still some kind of collision, timeout, or something happening apparently.

So, to work around this. I turn off the timer when i get a button press and do a thread.sleep(500) after the SendControltoFS - in order to give the simulator time to react to the input and update the display. Then I do a CDU display .process read and turn the timer back on to re-enable the refreshes. This turns out to be very reliable locally and remotely!

Getting really close now! If you have any ideas on why the one second timer refreshes interfere with the button presses let me know and I will be happy to try them. Otherwise I will just continue to use the timer off/timer on approach.

Thanks for your continued support!

Andy

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


×