YukonAV8

And this is the Arduino Uno with 2.8 inch display:

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

The new log file you posted is identical in timestamp to the previous log. Is it possible that when you did the reinstall you did not also reinstall FSUIPC? Do you see FSUIPC in the addon menu in FSX?

At the top of this page, click on and post there FSUIPC Support Pete Dowson Modules

Jaacques - this is posted in the sub-forum for the FSUIPC.Client DLL so it may not been seen by Pete or someone who can help you. You should post to the main forum. Rescan is used to switch between axis. So when you are done with one axis, press rescan to go on to the next one. If you want to delete the setting for an axis, uncheck the axis you assigned under the radio button for Send to FS as axis. You only use the Delete This button if you are using the right side of the dialog box I believe. First question, though - did you delete the joystick assignment for the Pedals from FSX so that it is not fighting with FSUIPC? Also, the CH Pro brakes require that you check 'rev' for reverse in the FSUIPC calibration dialog in order to work properly - that could explain why they are always on. If neither of these solves your problem, repost in the main forum and also be sure to specify what happens if you press one toe brake or both. Do you see 'BRAKES' or 'DIFFERENTIAL BRAKES' in Red in the lower left - or does it go out when you press the brakes indicating they are backwards? Andy

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

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

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

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

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

It is not clear how FSUIPC would affect rolling on the taxiway so maybe you could provide some more information about what exactly is happening and whether it is related to a joystick, what your configuration is, etc.

If you look in C:\Users\mdamm87\AppData\Roaming\Lockheed Martin\Prepar3D v3\dll.xml do you see an entry: <Launch.Addon> <Name>FSUIPC 4</Name> <Disabled>False</Disabled> <Path>Modules\FSUIPC4.dll</Path> </Launch.Addon> If that entry is there and still not showing up in the add on menu, I wonder if it has to do with the fact that you installed Prepar3d to the root of d:\ and not to a folder like d:\prepar3d Andy