Paul Henty Posted March 13, 2023 Report Posted March 13, 2023 12 hours ago, joeherwig said: The above script doesn't retrigger the calculator codes reliable as it seems. The first read is correct, but afterwards I don't get any further updates. For offsets the regular updates are fine. Can you monitor those LVars (A20N_L_TK_Pump_1_Off and A32NX_OVHD_INTLT_ANN) from somewhere else (e.g. The sim, John's WASM Client) and see if they are changing or not. I need to know if the calculator code is not updating them, or if my server is just not sending them to you. Quote Also got with Version V1.1.1 of FSUIPC WebSockets Server: When did you get this? It look like you pressed a button on the UI. Can you rememeber which button? Paul
John Dowson Posted March 13, 2023 Report Posted March 13, 2023 Could this be related to the new feature that scans for lvars and automatically pushed new lvars to WAPI clients? When this happens, all lvars are dropped and reloaded and must be re-registered for a callback (n the lvars-available callback function)? Note also that there is a new WASM/WAPI version available here: 5 hours ago, Paul Henty said: Can you monitor those LVars (A20N_L_TK_Pump_1_Off and A32NX_OVHD_INTLT_ANN) from somewhere else (e.g. The sim, John's WASM Client) and see if they are changing or not. You can monitor them manually by just listing them in either FSUIPC7 or the WASM Client application. For better monitoring, you can add them to an FSUIPC offset (using the FSUIPC7.ini [LvarOffsets] section) and then monitor the offsets using FSUIPC7's Log->Offsets feature. John
Paul Henty Posted March 13, 2023 Report Posted March 13, 2023 Quote When this happens, all lvars are dropped and reloaded and must be re-registered for a callback (n the lvars-available callback function)? That shouldn't be an issue. My dll detects the reload from the "fsuipcw_registerUpdateCallback" callback. Then it gets the new LVars list and re-registers all for callbacks (-1 parameter). Paul
joeherwig Posted March 13, 2023 Author Report Posted March 13, 2023 11 hours ago, Paul Henty said: I need to know if the calculator code is not updating them, or if my server is just not sending them to you. Quote I'm not at the sim right now... But I noticed, that when I ran the calculator code via FSUIPC7 the change of the changed Lvar is not published to the subscribers. But if I read the LVar within FSUIPC7 it shows the correct value. Hope, that helps at least a bit. I'll check asap and get back to you.
Paul Henty Posted March 14, 2023 Report Posted March 14, 2023 Quote Hope, that helps at least a bit Yes, thanks. That narrows it down a bit. I'll look into it over the next few days and get back to you.
Paul Henty Posted March 15, 2023 Report Posted March 15, 2023 I have access to MSFS for a month so I was able to try this here and it seems to work fine. Here is the code I ran in the Chrome console (I just modified yours to copy the parking brake into a custom LVar): function Sleep(milliseconds) { return new Promise(resolve => setTimeout(resolve, milliseconds)); }; let calccode = {command: 'vars.calc',name: 'calc',code: '(L:ParkingBrake_Position) (>L:PJH)', interval: 200} let declare = {command: "vars.declare",name: "myVarSet",changesOnly: true,vars: [{ name: "PJH" }]} let read = {command: "vars.read",name: "myVarSet",changesOnly: true, interval:200} let socket = new WebSocket("ws://localhost:2048/fsuipc/", "fsuipc"); socket.onopen = function(e) { socket.send(JSON.stringify(calccode)); Sleep(200); socket.send(JSON.stringify(declare)); Sleep(200); socket.send(JSON.stringify(read)); }; socket.onmessage = function(event) { console.log(`[message] Data received from server: ${event.data}`); }; socket.onclose = function(event) { if (event.wasClean) { console.log(`[close] Connection closed cleanly, code=${event.code} reason=${event.reason}`); } else { console.log('[close] Connection died'); } }; socket.onerror = function(error) { console.log(`[error] ${error.message}`); }; If I change the parking brake the L:PJH variable gets reported as changed with the correct value. Ran fine for about 10 mins until I stopped it. Maybe you could try the same. If it works, it would suggest the problem is somewhere other than the socket server. Paul 1
John Dowson Posted March 15, 2023 Report Posted March 15, 2023 FYI, I have release FSUIPC 7.3.18 and WASM 1.0.2 and WAPI 1.0.2. No API changes in the WAPI. John 1
joeherwig Posted March 25, 2023 Author Report Posted March 25, 2023 @John Dowson, @Paul Henty On trying to debug it seems, that I struggle on "redefining" or "killing" my LVar definitions. Of course on setting the interval for the vars.calc using the Websocket Server I'm able to stop the updating. Setting and interval > 0 afterwards re-enables the auto updating as expected. But when I again set a changed vars.calc definition with the same name and an interval > 0 and a new "calc" definition, it seems the old one is still active and can't be "redefined." The behaviour remains even after stopping and closing the websocket server, reloading the FSUIPC WASM (via FSUIPC Menu) and restarting the Websocket server. So after I set {command: "vars.calc", name: "calc2", interval: 200, code: "(A:FUELSYSTEM PUMP SWITCH:2, Enum) 0 == d (>L:A20N_FUELSYSTEM_PUMP_SWITCH2)"} I'm getting and then redefining it using {command: "vars.calc", name: "calc2", interval: 200, code: "222 (>L:A20N_FUELSYSTEM_PUMP_SWITCH2)"} I'd expect to be the LVar set each 200ms to a value of 200 but I don't get that. It still toggles between 0 and 1 on setting the afore mentioned Simvar. So if I want to check the CalcCodes, I currently always need to at least stop the Websocket Server and then reload the WASM from within FSUIPC and restart the Server. 1. Is there an working and easier option to reset the WASM and FSUIPC websocket and let them forget all the before commands including my LVars without restarting the sim and tools completely? I'd be happy to get an hint how to proceed best. Joe
Paul Henty Posted March 25, 2023 Report Posted March 25, 2023 Hi Joe, I'll check this tomorrow and see if I can reproduce the problem. I'll let you know what I find. Paul
joeherwig Posted March 25, 2023 Author Report Posted March 25, 2023 That's really great Paul. Thanks a lot! Probably it also helps to get this unhandled exeption error that has been thrown by the Websocket-Server: Quote See the end of this message for details on invoking just-in-time (JIT) debugging instead of this dialog box. ************** Exception Text ************** System.InvalidOperationException: Value Dispose() cannot be called while doing CreateHandle(). at System.Windows.Forms.Control.Dispose(Boolean disposing) at System.ComponentModel.Component.Dispose() at System.Windows.Forms.Control.Dispose(Boolean disposing) at FSUIPCWebSockets.Server.GUI.ctlPanel.Dispose(Boolean disposing) at System.ComponentModel.Component.Dispose() at FSUIPCWebSockets.Server.GUI.frmMain.setPanel() at System.Windows.Forms.Control.OnClick(EventArgs e) at System.Windows.Forms.Button.OnClick(EventArgs e) at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent) at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.ButtonBase.WndProc(Message& m) at System.Windows.Forms.Button.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) ************** Loaded Assemblies ************** mscorlib Assembly Version: 4.0.0.0 Win32 Version: 4.8.4614.0 built by: NET48REL1LAST_B CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/mscorlib.dll ---------------------------------------- FSUIPCWebSocketServer Assembly Version: 1.1.1.24 Win32 Version: 1.1.1.24 CodeBase: file:///H:/FSUIPC7/Utils/FSUIPCWebSocketServer.exe ---------------------------------------- System.Windows.Forms Assembly Version: 4.0.0.0 Win32 Version: 4.8.4550.0 built by: NET48REL1LAST_C CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll ---------------------------------------- System Assembly Version: 4.0.0.0 Win32 Version: 4.8.4605.0 built by: NET48REL1LAST_C CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll ---------------------------------------- System.Drawing Assembly Version: 4.0.0.0 Win32 Version: 4.8.4390.0 built by: NET48REL1LAST_C CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll ---------------------------------------- System.Configuration Assembly Version: 4.0.0.0 Win32 Version: 4.8.4190.0 built by: NET48REL1LAST_B CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll ---------------------------------------- System.Core Assembly Version: 4.0.0.0 Win32 Version: 4.8.4605.0 built by: NET48REL1LAST_C CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll ---------------------------------------- System.Xml Assembly Version: 4.0.0.0 Win32 Version: 4.8.4084.0 built by: NET48REL1 CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll ---------------------------------------- System.Numerics Assembly Version: 4.0.0.0 Win32 Version: 4.8.4084.0 built by: NET48REL1 CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Numerics/v4.0_4.0.0.0__b77a5c561934e089/System.Numerics.dll ---------------------------------------- System.Runtime.Serialization Assembly Version: 4.0.0.0 Win32 Version: 4.8.4536.0 built by: NET48REL1LAST_C CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Runtime.Serialization/v4.0_4.0.0.0__b77a5c561934e089/System.Runtime.Serialization.dll ---------------------------------------- System.Data Assembly Version: 4.0.0.0 Win32 Version: 4.8.4584.0 built by: NET48REL1LAST_B CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_64/System.Data/v4.0_4.0.0.0__b77a5c561934e089/System.Data.dll ---------------------------------------- ************** JIT Debugging ************** To enable just-in-time (JIT) debugging, the .config file for this application or computer (machine.config) must have the jitDebugging value set in the system.windows.forms section. The application must also be compiled with debugging enabled. For example: <configuration> <system.windows.forms jitDebugging="true" /> </configuration> When JIT debugging is enabled, any unhandled exception will be sent to the JIT debugger registered on the computer rather than be handled by this dialog box. It's quite strange... If I setup for instance {command: "vars.calc", name: "calc", interval: 200, code: "(L:A32NX_ELEC_AC_ESS_SHED_BUS_IS_POWERED) 1 == (A:FUELSYSTEM PUMP SWITCH:2, Enum) 0 == + d (>L:A20N_FUELSYSTEM_PUMP_SWITCH_OFF_ANNUN:F2)"} it works for quite well a while before it stops working and doesn't update the LVar anymore. within the logfile I couldn't find anything valuable. If I set the LogLevel to DEBUG, I get quite a lot of crashes... So sorry for being not more helpful at the moment. Joe FSUIPC_WASM.log
Paul Henty Posted March 25, 2023 Report Posted March 25, 2023 Quote Probably it also helps to get this unhandled exeption error that has been thrown by the Websocket-Server: I'll look at that as well, but I need to know how to reproduce it. The call stack suggests it's after a button press. Which one? Paul
joeherwig Posted March 26, 2023 Author Report Posted March 26, 2023 Take the FBW A32nx. On the overhead the fuel tank pump 1 left Check the updating of the (off) LED annunciator which should only be on, if the bus is powered and the fuse is in and either the pump is off or the annunciator light testis active. According to hubhop. Mobiflight there is an working output calccodee but i tried simpler ones as well..
Paul Henty Posted March 26, 2023 Report Posted March 26, 2023 I meant how to reproduce the exception you posted. From the call stack it looks like you pressed one of the buttons on the UI. Can you remember which one? Paul
joeherwig Posted March 26, 2023 Author Report Posted March 26, 2023 In Your Server, i tried to "reload" within the MSFS variables tab. I expected, it would do the WASM reload as from within the FSUIPC7 Add-ons | WASM | Reload Function. But in my case it crashes the Websocket Server.
Paul Henty Posted March 26, 2023 Report Posted March 26, 2023 Hi Joe, I've tested the user interface here and I can't get it to throw that exception. Tried lots of reloads, lvar lists, running a client against it for 20mins etc. Does it happen every time you press reload? I also tested changing the Calc Code while it's running. Again no problems at all. I was able to send a new calc message with different code and it just executed the last one. e.g. {command: 'vars.calc',name: 'calc',code: '(L:ParkingBrake_Position) (>L:PJH)', interval: 200} then {command: 'vars.calc',name: 'calc',code: '(L:TAXI_LIGHTING_1) (>L:PJH)', interval: 200} then {command: 'vars.calc',name: 'calc',code: '222 (>L:PJH)', interval: 200} I'm not sure what's going on on your system, but I'm pretty sure the WebSocketServer code is not the problem. Paul
joeherwig Posted March 27, 2023 Author Report Posted March 27, 2023 Hm... Tried it a lot right now... Seems to be a timing issue as well when the vars.calc is sent. So if I wait inbetween it seems to work. function sleep(delay) { var start = new Date().getTime(); while (new Date().getTime() < start + delay); } let calc = { command: "vars.calc", name: "calc", code: "(A:FUELSYSTEM PUMP SWITCH:2, Enum) (>L:A20N_FUELSYSTEM_PUMP_SWITCH:2)", interval: 200 }; let calc2 = { command: "vars.calc", name: "calc2", code: "(A:FUELSYSTEM PUMP SWITCH:2, Enum) 0 == (L:A32NX_OVHD_INTLT_ANN) 0 == or 1 and (L:A32NX_ELEC_AC_ESS_SHED_BUS_IS_POWERED, Bool) and (L:A32NX_OVHD_INTLT_ANN, number) 2 == if{ 1 } els{ 1 } * (A:CIRCUIT GENERAL PANEL ON, Bool) * (>L:A20N_FUELSYSTEM_PUMP_SWITCH_OFF_ANNUN:2)", interval: 200 }; let declare = { command: "vars.declare", name: "myVarSet", changesOnly: false, vars: [ { name: "A20N_FUELSYSTEM_PUMP_SWITCH:2" }, { name: "A32NX_ELEC_AC_ESS_SHED_BUS_IS_POWERED"}, {name: "A20N_FUELSYSTEM_PUMP_SWITCH_OFF_ANNUN:2"}, {name: "A32NX_OVHD_INTLT_ANN"}, {name: "A20N_CIRCUIT_BREAKER_GENERAL_PANEL_ON"} ] } //let vars = {command: 'vars.list', name: 'list',notify: 'auto' } let read = { command: "vars.read", name: "myVarSet", changesOnly: false, interval:200 } let socket = new WebSocket("ws://myIP:2048/fsuipc", "fsuipc"); socket.onopen = function(e) { sleep(200); socket.send(JSON.stringify(calc)); sleep(2000); socket.send(JSON.stringify(calc2)); sleep(2000); socket.send(JSON.stringify(declare)); sleep(2000); socket.send(JSON.stringify(read)); }; socket.onmessage = function(event) { console.log(`[message] Data received from server: ${event.data}`); }; socket.onclose = function(event) { if (event.wasClean) { console.log(`[close] Connection closed cleanly, code=${event.code} reason=${event.reason}`); } else { console.log('[close] Connection died'); } }; socket.onerror = function(error) { console.log(`[error] ${error.message}`); }; Regarding the crashes... You can reproduce it, if you send in an CalcCode causing an error and you get the Message Quote [ERROR]: Error setting Client Data Calculator Code: '... and then try to "Reload" from that tab, in my case it freezes the application reproduceable. To avoid that, I first stop the Websocket on the "Web Services" Tab, then do the "Reload" and afterwards re-enable the Web Socket serving and need to reconnect. Not sure, whether that makes sense... But at least it helped. As long as I only update the vars.calc with codes that do not cause throwing errors within the application UI I can confirm, that I can update hundreds of Times without Issues. For me it seems that sending a faulty CalcCode will be the "calcCode of death" ;-). So probably there's room for improvement on error-handling. What about checking whether a CalcCode is throwing the above error and then stopping with sending it again and just displaying something like the above just once? Probably the timing-issue can be fixed as well. The same code sometimes works and sometime doesn't... Waiting long enough solves it. It would be really helpfull, if there is a timing issue with the variable service on sim side, if the Websocket server could ensure the required delay before pushing the received commands to the sim. Hope that helps a bit. And keep up the great work! Really love working with it. The options it provides are really great! Joe
joeherwig Posted March 27, 2023 Author Report Posted March 27, 2023 Ah... I suppose also about the timing stuff... Sending the following (looped through) commands fast one after another, {"command":"vars.calc","name":"calcCode_wifinode-overhead_1","code":"(A:FUELSYSTEM PUMP SWITCH:2, Enum) 0 == (L:A32NX_OVHD_INTLT_ANN) 0 == or 1 and (L:A32NX_ELEC_AC_ESS_SHED_BUS_IS_POWERED, Bool) and (L:A32NX_OVHD_INTLT_ANN, number) 2 == if{ 1 } els{ 1 } * (A:CIRCUIT GENERAL PANEL ON, Bool) * (>L:A20N_FUELSYSTEM_PUMP_SWITCH_OFF_ANNUN:2)","interval":200} {"command":"vars.calc","name":"calcCode_wifinode-overhead_2","code":"(A:FUELSYSTEM PUMP SWITCH:5, Enum) 0 == (L:A32NX_OVHD_INTLT_ANN) 0 == or 1 and (L:A32NX_ELEC_AC_ESS_SHED_BUS_IS_POWERED, Bool) and (L:A32NX_OVHD_INTLT_ANN, number) 2 == if{ 1 } els{ 1 } * (A:CIRCUIT GENERAL PANEL ON, Bool) * (>L:A20N_FUELSYSTEM_PUMP_SWITCH_OFF_ANNUN:5)","interval":200} {"command":"vars.calc","name":"calcCode_wifinode-overhead_3","code":"(A:FUELSYSTEM PUMP SWITCH:1, Enum) 0 == (L:A32NX_OVHD_INTLT_ANN) 0 == or 1 and (L:A32NX_ELEC_AC_ESS_SHED_BUS_IS_POWERED, Bool) and (L:A32NX_OVHD_INTLT_ANN, number) 2 == if{ 1 } els{ 1 } * (A:CIRCUIT GENERAL PANEL ON, Bool) * (>L:A20N_FUELSYSTEM_PUMP_SWITCH_OFF_ANNUN:1)","interval":200} {"command":"vars.calc","name":"calcCode_wifinode-overhead_4","code":"(A:FUELSYSTEM PUMP SWITCH:4, Enum) 0 == (L:A32NX_OVHD_INTLT_ANN) 0 == or 1 and (L:A32NX_ELEC_AC_ESS_SHED_BUS_IS_POWERED, Bool) and (L:A32NX_OVHD_INTLT_ANN, number) 2 == if{ 1 } els{ 1 } * (A:CIRCUIT GENERAL PANEL ON, Bool) * (>L:A20N_FUELSYSTEM_PUMP_SWITCH_OFF_ANNUN:4)","interval":200} {"command":"vars.calc","name":"calcCode_wifinode-overhead_5","code":"(A:FUELSYSTEM PUMP SWITCH:3, Enum) 0 == (L:A32NX_OVHD_INTLT_ANN) 0 == or 1 and (L:A32NX_ELEC_AC_ESS_SHED_BUS_IS_POWERED, Bool) and (L:A32NX_OVHD_INTLT_ANN, number) 2 == if{ 1 } els{ 1 } * (A:CIRCUIT GENERAL PANEL ON, Bool) * (>L:A20N_FUELSYSTEM_PUMP_SWITCH_OFF_ANNUN:3)","interval":200} {"command":"vars.calc","name":"calcCode_wifinode-overhead_6","code":"(A:FUELSYSTEM PUMP SWITCH:6, Enum) 0 == (L:A32NX_OVHD_INTLT_ANN) 0 == or 1 and (L:A32NX_ELEC_AC_ESS_SHED_BUS_IS_POWERED, Bool) and (L:A32NX_OVHD_INTLT_ANN, number) 2 == if{ 1 } els{ 1 } * (A:CIRCUIT GENERAL PANEL ON, Bool) * (>L:A20N_FUELSYSTEM_PUMP_SWITCH_OFF_ANNUN:6)","interval":200} I get { "command": "vars.calc", "name": "calcCode_wifinode-overhead_1", "success": true, "errorMessage": null, "errorCode": null } which is fine. But afterwards I receive a couple of times the following: { "command": "Unknown", "name": "Unknown", "success": false, "errorMessage": "Additional text encountered after finished reading JSON content: {. Path '', line 1, position 355.", "errorCode": "BadMessage" } Unfortunately without the "wrong" JSON content nor the command nor its name. So it's hard to check for me. Joe
Paul Henty Posted March 28, 2023 Report Posted March 28, 2023 Thanks for all the extra investigation. I managed to reproduce the problem here and I think I've tracked it down to a threading issue in the websocket server. Please try the attached and let me know how you get on. FSUIPCWebSocketServer_V1.1.2-Beta.zip Paul
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now