Testing version 3 RC2 - occasional double entry required

[YukonAV8]

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

 

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

[Paul Henty]

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

[YukonAV8]

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

 

[YukonAV8]

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

[Paul Henty]

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

 

[YukonAV8]

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

[Paul Henty]

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

[Paul Henty]

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

[Paul Henty]

Hi Andy,

Please try the attached version. Should be much more reliable now.

FSUIPCClient3.0_RC4.zip

[YukonAV8]

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

 

[YukonAV8]

I think I may have found why the refresh is interfering with the button presses, not positive, but if I am right, Paul - it is NOT a problem your code!

I used some diagnostic.stopwatches and found that the operation which parses the 1008 byte CDU string into the rich text box. is very slow. This is because the RTB is probably trying to paint it as I make changes. SO, I created a second, hidden rich text box and did the parsing to there and then at the end, copied the rich text data to the visible box. This reduced the time required from over 100ms to less than 2 ms per refresh. 

I attached a picture of what the app looks like, fyi.

Andy

[YukonAV8]

And this is the Arduino Uno with 2.8 inch display:

 

[Paul Henty]

Looks very nice.

The problem does sound like some kind of timing issue, so managing when the two operations happen is probably the best solution. Speeding up the CDU read should also help a lot. If that timer is executing on the UI thread (i.e. it's System.Windows.Forms.Timer) then it will block key/mouse events until it's done.

I'm not clear if, when you get key drops, they show up in the FSUIPC write log. I suspect not as the UI event isn't running. If that's the case then I think you've identified the problem and the solution.

Paul