[Defining SimVars in LUA]

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

[Defining SimVars in LUA]

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).

[APU Bleed start engines Project Magenta 738]

3 minutes ago, John Dowson said:

Can you verify the attached please. This is the version  I will release tomorrow, v7.3.0

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

[APU Bleed start engines Project Magenta 738]

5 minutes ago, John Dowson said:

can you try the attached (haven't changed the version)

That's working again. Thank you.

[APU Bleed start engines Project Magenta 738]

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.

 

[APU Bleed start engines Project Magenta 738]

5 hours ago, John Dowson said:

Not sure what you mean by this, but there is a change in this version with the ipcReady.lua. In this version, the ipcReady.lua is not started until lvars/hvars have been received by FSUIPC.

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

[APU Bleed start engines Project Magenta 738]

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.

 

[APU Bleed start engines Project Magenta 738]

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

[APU Bleed start engines Project Magenta 738]

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().

[APU Bleed start engines Project Magenta 738]

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).

[Reading FSUIPC Controls]

11 minutes ago, John Dowson said:

if you would like to try this

I will take a look later thank you.

[FSUIPC Lua Library Document 7.2.16]

Hi John#

1 hour ago, John Dowson said:

How come you get different logging? Did you re-install and install the WASM?

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.

[FSUIPC Lua Library Document 7.2.16]

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

[FSUIPC Lua Library Document 7.2.16]

18 minutes ago, John Dowson said:

Are you sure that is from the latest release? Can you check and show me the full log file. And did you also reinstall the wasm?

I will check further on that message tomorrow, but it shouldn't be an issue..

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

[FSUIPC Lua Library Document 7.2.16]

Just now, John Dowson said:

Btw, I am looking to add functionality to add any simvar (or MSFS A type variables) to a free user offset for the next release. Couldn't fit it in to this one (didn't want to delay any longer!), but should hopefully be ready for release by early next week.

John

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.

[FSUIPC Lua Library Document 7.2.16]

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

[Missing Hvars for FBW A320 in 7.2.15]

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

[Missing Hvars for FBW A320 in 7.2.15]

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.

[Reading FSUIPC Controls]

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

[Reading FSUIPC Controls]

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?

[LVARs]

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.

[VRInsight and Lvar Updates]

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

[Width of FSUIPC7 Dropdown Menus]

Thank you John

[VRInsight and Lvar Updates]

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

[VRInsight and Lvar Updates]

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.