Scotfleiger

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

Hi John/Pete I have tracked down the source of the problem. There appears to be a clash with output to VRi Combo MCP (com3) and key presses on the VRi CDU3 (com4). When a write command to com3 (eg. DSP8100) occurs it is blocking one or more reads from com4 (eg. KEY1). The 2 serial-to-USBs are connected to different USB hubs which suggests it is not a hardware issue. Attached is an extract of the FSUIPC7.log with Log Bit 6 set (VRICOM). The VRI com3 <- lines are the write to the MCP and the CDUcontrols lines are logged by the LINDA event handler when keys are pressed on CDU (uses event.VRIread(dev2, "CDUcontrols")). Sometimes all key presses are captured, but when a write occurs you can see the missed key presses. The LINDA MCP display code is written to avoid unnecessary writes when the display data is unchanged. Otherwise, the display update is 1Hz. VRICOM.txt

Hi @Pete Dowson Just for clarification on above. LINDA uses the event.VRIread to set up call to the VRI device handlers. With the CDU3 if I press the keys too quick (normal pace) some events are missed and input lost. Not all events are being presented for processing. For example, pressing 1, 2, 3, 4, 5, 6, 7, 8, 9 in sequence returns events for 1, 2, 3, 8, 9 missing 4, 5, 6, 7. This varies between tests. I have to pause between key presses to ensure a key events is generated correctly. Sometimes a key press is repeated/read twice.