Scotfleiger

With FSUIPC7 7.3.1 running, user is still seeing multiple Exception 1 ERROR on TransmitClientEvent. Any ideas? I have not seen these errors with similar configuration (FBW A320 Neo with VRI MCP2a Airbus). Also, but probably unrelated, the user is only reporting a third of the expected Lvars (~1000 of expected ~3000). FSUIPC7.log.txt

Hi John One of my users is logging multiple TransmitClientError exception errors. Can you suggest what might be causing FSUIPC7 to log these (small sample only)? 371531 Exception 1 "ERROR", Ref 4983, Index param 2 on TransmitClientEvent, object=1, id=32773 (????), data=0 371578 Exception 1 "ERROR", Ref 4984, Index param 2 on TransmitClientEvent, object=1, id=32773 (????), data=0 371656 Exception 1 "ERROR", Ref 4985, Index param 2 on TransmitClientEvent, object=1, id=32773 (????), data=0 371719 Exception 1 "ERROR", Ref 4986, Index param 2 on TransmitClientEvent, object=1, id=32773 (????), data=0 Full fsuipc7.log attached. FSUIPC7 7.2.16 being used. FSUIPC7.log.txt

Thanks for the quick response. I fully understand your reasoning. I will hold off in requesting any reserved offsets at the moment.

Hi John The MyOffsets.txt means of the user defining SimVars is a great step forward. It has the disadvantage of requiring developers to define and distribute a copy of this file which may overwrite user's own files and would require a different file for each aircraft. Would it be possible to define such offsets using LUA? For example, ipc.defineOffset(0x66c0,1,CIRCUIT SWITCH ON:18,I32,Bool).

This version is working fine. The interface is behaving as expected.

That's working again. Thank you.

Hi John Thank you for the quick response. 7.2.17e is still not allowing any IPC with LINDA. Switching back to 7.2.17c restores correct operation.

Hi John Something has definitively been broken. LINDA uses the reserved offsets 0x7320 to 0x735F to communicate between its 2 parts - the GUI linda.exe and the LUA code (see initialisation snippet below). This is achieved by the GUI relaying instructions via the x_EXEC 60-byte block which triggers an offset event. The LUA acknowledges by resetting the x_QUEUE flag. A reload command restarts the LUA code boot via x_RELOAD. Neither of the event.offsets are being triggered with 7.2.17d from what I can see. This is what I mean when I say the inter-process communications (IPC) has been broken. The event.timer is working. The LUA code is starting via ipcReady.lua and running correctly but I cannot control it from the GUI. I did try the ipcInit.lua. -- communication offsets x_RELOAD = 0x7320 -- I/0 reload configs x_EXEC = 0x7321 -- action string max 60 bytes x_LUARDY = 0x735D -- LUA ready 1:busy, 0:ready x_LUAEVT = 0x735E -- LUA events initialised 1:busy, 0:done x_QUEUE = 0x735F -- queue flag - 1:busy, 0:ready to receive -- set up timer events event.offset(x_RELOAD, "UB", 1, 'offset_reloadConfigs') event.offset(x_EXEC, "STR", 60, 'offset_executeCommand') event.timer(20, "hidPoll") -- main timer event 50Hz LINDA cannot use this update as is. PS. I agree that the odd Lvars were a result of the add-on. FSUIPC7.log

Morning John I hit some problems with the new build 7.2.17d last night and confirmed this morning. The inter-process communication between FSUIPC7 and LINDA has been broken. I am no longer able to reload Lvars and some other status information (FSUIPC Ready) is no longer working. Unfortunately, I won't be able to investigate further until after the weekend due to other commitments.

Hi John I retested with 7.2.17d as requested. I am receiving the same alphanumeric Lvars (see attached of all Lvars found). FSUIPC WASM/List Lvars is returning the same items all set to zero (0.000000). In addition to the 13 at the start of the list, there are others scattered throughout the list. The LINDA code used to search for the Lvars looks for the all non-Nil values returned by ipc.getLvarName(): local vars = {} -- generate list i = 0 while i < 65536 do name = ipc.getLvarName(i) if name == nil then break end i = i + 1 if name ~= '' then vars[i] = name end end This code has not changed from previously and it is the first time it has returned odd looking Lvars. STOP PRESS: Looking at the FSUIPC7.log these odd Lvars are bracketed by Lvars for the Ambitious Pilots Toolbar Push Back add-on. I will investigate after I find a way to uninstall the add-on. Test conditions: Started MSFS with FBW 32NX Experimental, started LINDA 4.1.4a and then started FSUIPC7. lvars.lst FSUIPC7.log

Hi John With the test build 7.2.17c I am seeing some random alphanumeric Lvars listed with the FBW A32NX (see attached). I have checked with FBW on Discord and they say they are not theirs. This is with a clean start of MSFS and FBW Experimental build. These are seen with FSUIPC7 List Lvars and my scan with LINDA using ipc.GetlvarName().

Hi John This is great. I tried a simple boolean example for the FBW A32NX. // offsets, size, simvar, type, units [, w] 0x66C0, 1, EXTERNAL POWER AVAILABLE, I32, Bool 0x66C1, 1, EXTERNAL POWER ON, I32, Bool I would be useful to be able to use the UB and UW sizes in addition to the I32 (UD). One reason is that the EXTERNAL POWER AVAILABLE is defined as a 0 or 1 but when power is available and turned on FBW set bit 17 to give 257 (0x101). When power is not available but it is turned on the same bit is set = 256 (0x100).

I will take a look later thank you.

Hi John# The different logging was because I turned down the level of LINDA logging. No additional installation (WASM) was done between last night and this morning. The only difference was shutdown everything in between. I should have checked the InstallFSUIPC7.log. This appears correct although no version numbers quoted. It was my typo - FSUIPC7 used throughout. The new ipc.reloadWASM option appears to be working well - all Lvars/Hvars now visible when triggered. Thanks again.

Morning John I attach the full fusipc7.log (includes LINDA logging) from last night. The relevant lines are: 9219 [INFO]: **** Starting FSUIPC7 WASM Interface (WAPI) version 0.5.6 (WASM version 0.5.7) 9219 [INFO]: Connected to MSFS 9735 [ERROR]: **** Different WASM version: The WASM version is 0.5.6 while the WAPI version is 0.5.7. This may cause issues. This morning I get the same INFO lines but no error. 8500 Starting WAPI... 8500 [INFO]: **** Starting FSUIPC7 WASM Interface (WAPI) version 0.5.6 (WASM version 0.5.7) 8500 [INFO]: Connected to MSFS The change.txt refers to WASM updated to 0.5.7 but I can't find FSUIPC7_WASM.WASM in the 7.2.16 download. The version on fsuipc.com is 0.5.6. According to the Installing and Registering document states that FSUIPC7_WASM.WASM file will be installed in my /community/fsuipc-lvar-module/modules directory. The current file is dated 6 Feb 22. You mention that I need to update WASM but surely this should be part of the FSUIPC6 installation process. If I am confused I am sure most users will be in a similar position. FSUIPC7.log FSUIPC7 - Copy.log

I will recheck tomorrow. No I didn’t reinstall WASM. I just ran the Install FSUIPC.EXE.

That will great. One other thing. I am seeing [E] [ERROR] **** Different WASM version: The WASM version is 0.5.6 while WAPI version is 0.5.7. This may cause issues. in FSUIPC.log.

Hi John There is a small typo in the Lua Library manual for 7.2.16. ipc.getLHarName(id) should read ipc.getHvarName(id) on Page 4. Andrew

Thank you John. I think I missed the earlier discussion.

Hi John The Hvar file for A32NX FBW distributed with the formal release of 7.2.15 is empty. I did a reinstall to confirm this.

Thank you again for the explanation and insight to your plans.

Hi John Traditionally, FSUIPC Controls are used as events to trigger or send parameters using ipc.control(). FlyByWire has defined many MSFS Variables as Read/Write. An example is LIGHT_POTENTIOMETER:7 for the A32NX Dome Light. As MSFS Variables translate to Controls is there thought of being able to read these values?

Hi John I can confirm @kingm56's report. The Lvars are not 'purged' when a new aircraft is selected. You end up with a mixture from both.

Hi John As suggested I have run a test with P3D v5.3.15 and FSUIPC6 6.1.7. With both VRI MCP (Airbus) (com3) and CDU3 (com4) connected, I repeated the same CDU key press test and found that all key events were captured even when 'interrupted' by data writes to the MCP (1Hz). It did not matter how quickly I pressed the keys - all were captured and actioned. There definitely appears to be a difference between FSUIPC6 and FSUIPC7 event.VRIread() handling. I don’t think can be explained by the use of .EXE vs .DLL as the handling of the comms should be independent of the Flt Sim and SimConnect. This is not an urgent matter as I suspect few users have both these hardware devices. P3D_VRICOMD.txt

Thank you John