Luke Kolin

One challenge I have with my software is that FSUIPC_Process calls will take a variable amount of time, with some significant delays at times. I've instrumented the SendMessageTimeoutA call on my end and while it usually averages around 16-20ms to return, there are significant outliers where it can take up to 2000ms or more. Even on my own machine I'm seeing data like this: FSUIPC!!SendMessage 71,377x Avg:16.47ms Min/Max=0.03/681.98ms ... which is a max of almost 700ms. This is of course less than ideal because in previous versions the UI would block. I've moved on and made those calls in their own thread, but the FSUIPC interface itself on my end is single threaded. John/Pete, when I make that SendMessage call to either FSUIPC or the simulator process, if the frame rate remains decent (double-digits, say) what would cause such delays? I assume that FSUIPC is listening for these Windows messages on a per-frame basis, so it should get handled in under 100ms? My users all swear up and down that their frame rates are excellent (and I'd rather not instrument that any more than I have) but are there any cases that you know of where FSUIPC will take an excessive amount of time to respond? Cheers!

Ray, I can't speak to the correctness of that sequence but have you considered just writing to the door LVARs? That seems to have fewer state issues and certainly a lot less work and timings to go wrong. Cheers!

Things look good here. I'm enclosing the log, INI, and Lua script in case you need them. (FWIW right when the script starts it takes focus away and then refuses to give it back for 3-5s, but that's been there for a while.) Cheers! cs7x7ap.lua FSUIPC6.ini FSUIPC6.log

Yes, that's actually why I needed to restart - when debugging to fix silly mistakes like that one. 😄 I'm enclosing two logs. The first is with a hang, the second without. The only difference is again the com.close() - for some reason that is making things unhappy. I don't have a problem keeping it commented out, but the old programmer in me still feels a little unclean at not cleaning things up when I'm done. (My wife says that doesn't stop me around the house.) Cheers! FSUIPC6.log FSUIPC6_prev.log

So, another interesting data point. I have a key binding set in FSUIPC to restart my LUA scripts which is helpful when debugging and updating them. It just runs LUA <script> which starts it if it has terminated, or kills the existing script if running. Now, it seems to hang P3D... perhaps I'm not cleaning up properly? here's the log. Cheers! FSUIPC6.log

The most recent DLL in this thread looks good, both for the equipment code (0x6CID) and tail code (0x6C3C). I suppose I can check the door status as well to validate the padding on the other blocks but I think that will be good too. The earlier DLL did _not_ work. FWIW I got some differing messages regarding LUA shutdown handlers like we discussed earlier. I don't believe it's at all related and doesn't seem to harm anything, but I am enclosing in case it triggers a eureka moment on your end. Cheers FSUIPC6.log FSUIPC6_prev.log

If Jason doesn't get to it today, I'll take a peek after I go to get shot. What exactly is new? I have a document dated November 2016 that has all this. I'm pretty certain it all works correctly; I do a sanity check on the flight number IIRC. Cheers!

Normally. I turned off all of the debug messaging because it was changing the timings too much. Cheers!

I made some changes and I think I got them all (param, poll, and terminate) but I'm still getting the termination warning. I'm not going to sweat it since it seems to clean up OK. Thanks for your help in understanding the Lua system better. Cheers!

That makes sense. I'll try that. Cheers

Sorry, I'm not worried about the latency - I understand why that happens. This is the part that is interesting to me: 112578 LUA.1: Event canceled 112578 LUA.1: ...ke\Documents\Prepar3D v4 Add-ons\FSUIPC6\cs7x7ap.lua:101 112578 LUA.1: CS757/767 Button Handler shutdown 112578 LUA.1: ...ke\Documents\Prepar3D v4 Add-ons\FSUIPC6\cs7x7ap.lua:103 112578 LUA.1: Waiting for an event in "C:\Users\Luke\Documents\Prepar3D v4 Add-ons\FSUIPC6\cs7x7ap.lua" 113750 Lua threads being terminated: 113750 1 = "C:\Users\Luke\Documents\Prepar3D v4 Add-ons\FSUIPC6\cs7x7ap.lua" 113922 LUA: "C:\Users\Luke\Documents\Prepar3D v4 Add-ons\FSUIPC6\cs7x7ap.lua": killed 113922 === Closing global Lua thread By line 103, I've already called event.cancel() so why is it waiting for an event right afterwards? Cheers

So I turned on a lot of debugging (which seemed to cause some latency and interesting race conditions) and I've attached the log. Note at the end, even after event.cancel it looks like LUA is still waiting on an event, and perhaps the cancel() isn't working? Attaching log and LUA so you can see the line numbers. Cheers FSUIPC6.log cs7x7ap.lua

Looks clean now! Interestingly the com.close appears to take a while... I've enclosed the log and the shutdown function (I've changed the logic a bit as we've been working and can't remember if you've seen it). function HandleShutdown() if (hidHandle ~= 0) then ipc.log("Shutting down USB device hnd=" .. hidHandle) com.close(hidHandle) ipc.log("USB Device disconnected") hidHandle = 0 event.cancel("HID_Poll") ipc.log("Event canceled") end ipc.log("CS757/767 Button Handler shutdown") end FSUIPC6.log

I tried the last plugin with TimeForLuaClosing=5, and got the following log. Do you want me to try the earlier ones as well? Cheers! FSUIPC6.log

OK. Thanks!

It definitely made a difference. I got a warning, but the process terminated. Cheers! FSUIPC6.log

Sorry, brain fart - I removed event.cancel(). I'll remove event.terminate as well. Cheers

No change. Here's the log and INI. Cheers FSUIPC6.ini FSUIPC6.log

Doesn't appear to make a difference. I've attached the full log/ini files, and here is the relevant function: function HandleShutdown() if (hidHandle ~= 0) then ipc.log("Shutting down USB device hnd=" .. hidHandle) com.close(hidHandle) ipc.log("USB Device disconnected") hidHandle = 0 -- event.cancel("HID_Poll") -- ipc.log("Event canceled") end ipc.log("CS757/767 Button Handler shutdown") end You can say for sure, but my uninformed guess is that the com.close is throwing an error that isn't getting caught or logged. I'll try again with the parameter set to 5. Cheers FSUIPC6.log FSUIPC6.ini

Interestingly, I checked my INI and the parameter was already there... set to 2. I'll try again with the event.terimate removed. Cheers

So I changed the shutdown function to be this: function HandleShutdown() if (hidHandle ~= 0) then ipc.log("Shutting down USB device hnd=" .. hidHandle) com.close(hidHandle) ipc.log("USB Device disconnected") hidHandle = 0 event.cancel("HID_Poll") ipc.log("Event canceled") end ipc.log("CS757/767 Button Handler shutdown") end So I'll close, log, then cancel. I didn't even get the log message: 72484 -------------------- Starting everything now ---------------------- 72563 ASN active function link set 72563 Ready for ActiveSky WX radar with additional data 72563 LUA.1: USB Device Connected, hnd=1 72563 LUA.1: Poll loop started 72563 LUA.1: Registered CS757/767 Button Handler 73641 Advanced Weather Interface Enabled 103406 Sim stopped: average frame rate for last 39 secs = 34.8 fps 103406 Max AI traffic was 5 aircraft 103406 ------------------------------------------------------------------- 108984 === Closing session: waiting for DLLStop to be called ... 119719 === DLLStop called ... 119719 === Closing external processes we started ... 120719 === About to kill any Lua plug-ins still running ... 120719 LUA.1: Shutting down USB device hnd=1 120875 Lua threads being terminated: 120875 1 = "C:\Users\Luke\Documents\Prepar3D v4 Add-ons\FSUIPC6\cs7x7ap.lua" 121172 **** DevCom read/write threads still running - will exit anyway but could cause issues... 121313 LUA: "C:\Users\Luke\Documents\Prepar3D v4 Add-ons\FSUIPC6\cs7x7ap.lua": killed 121766 **** DevCom read/write threads still running - will exit anyway but could cause issues... ... so I think you're correct about com.close() taking too long. Is there any possibility to increase the cleanup limit? 5ms seems awfully short. Cheers

That's the complete log. I'll try commenting out the event.cancel and add some additional logging details to see if it makes a difference, and report back. Cheers!

I've implemented some LUA scripts to handle extended button reads, and I've noticed that P3D isn't shutting down properly at times. Looking at my logs, it appears that my Lua shutdown function is terminating abnormally. I call event.cancel() and then com.close() but it looks like one is failing and then the script is getting terminated by FSUIPC. The changelog for 6.1 suggests that there are some changes in com handling. Am I doing things incorrectly? Is there a conflict with the new button handling post-6.0.12? Cheers! Luke FSUIPC6.log cs7x7ap.lua

I have the Honeycomb Bravo throttle quadrant, and I use the software for configuring the lights and some of the buttons (specifically, the PMDG autopilot integration). However, there's nothing stopping you from using it as a regular joystick with FSUIPC. Cheers! Luke

There are four areas I recognize I am ignorant in and leave it to the experts - thread synchronization, dates/times, encryption and character encoding. 😄 From what little I know, UTF-8 and UTF-16 should be a superset of ASCII, so regular ASCII characters should be encoded the same way in all three. It should a simple modification to change the signature for that function and any comparisons it does, then see what happens. I'd be slightly surprised if that's all it took to make it work, but even more surprised if that broke the ASCII case. YMMV, of course. Cheers Luke