Scotfleiger

I am as much in the dark as you regarding Lvars and their inclusion in SimConnect. Normally, default aircraft do not use Lvars, only those from 3rd party developers like PMDG. I will take a look at the G36.

@szeliga90 Based on the original MS spec, the control for the Fuel Pump is 66237. This turns on/off all fuel pumps (up to 4). The status of the Fuel Pump switch is indicated by offset 0x3104 (0 off/1 on). You can also use the offset 0x3125 to set the available pumps on/off (bit 0=pump 1, bit 1=pump 2, bit 3=pump 3, bit 4=pump 4). There are also controls 66339-66343 that toggle the electrical fuel pumps (all/1/2/3/4). This has the same effect as above. I can find no Fuel Pump High option and I don't have the B58 in my available aircraft to check. I suggest this setting is outside the defined offset/control range and relies on internal variables (Lvars) not yet exposed through SimConnect.

Thank you. I had not seen that behaviour but it makes sense.

At present, you have to go to the system tray, right on icon and click show to display the FSUIPC7 window. This enables users to confirm that it is connected to MSFS. My suggestion was for the window state (show/not show) be remembered in FSUIPC7.ini so that it returns to the last selected state when FSUIPC7 is started. It does not to be always on top.

@RainerM if I might chip in here. I do not use SerialFP2 with my VRI MCP panels except to install the FTDI serial to USB drivers. As the support developer I would recommend you investigate LINDA 3.2.6 which works with all VRI combo MCP panels and P3Dv5. There is a 30s delay on P3D closing before the MCP is released. This was added to FSUIPC6 to ensure that the P3D background task correctly terminated. This should solve your issue.

An additional delay was added in FSUIPC6 when it closes to ensure that LINDA could correctly terminate before the VRI MCP connection was terminated. This was because a P3D background task was left hanging. LINDA does not use the SerialFP2. I will read and reply to the thread.

I do not believe there is any additional slowing down when reading and writing to VRi Combo MCP panel comport. I found I had a coding error (bad reference) that was stopping me getting the read working. Your advice allowed me to track this down and fix it. Using LUA with ipc.control statements does not show any observable delay when changing data (like heading).

Thank you for access to the FSUIPC7 7.0.0-beta (26 Aug 2020). May I make a few suggestions before you formalise the release? The Show window should be made persistent. The FSUIPC7.exe File Description property should be changed to 'FSUIPC7 for MSFS'. At present the Task Manager process name appears as 'IPC Interface and More, for MSFS' which may not be clear to users. I have checked the following offsets as set out in offset status 0.3: 0x3124 = Flight Simulator version (1 byte) MSFS = 110 for version 11. 0x3304 = FSUIPC version (4 bytes) in hex 0x70000002 = 7.0.0 0x3308 = Flight Simulator Release (2 bytes) gives '13' (xD) for MSFS (P3D-64 bit was 12 and FSX 8). I hope this is useful.

Just for feedback. With the debug options you suggested and LogOptionProtect=no, I was able to see all read and write to Vri COMPORT and I can confirm that the MCP is working correctly for me.

Thanks Pete. I suspect you are correct about the SimConnect delays. I have removed as much load as I can and am getting a high fps but I can see delays in processing of inputs/outputs.

I have been testing FSUIPC7 with LINDA. I am able to output data to the VRInsight MCP panel without problem. However, receiving data (ie buttons) is problematic or intermittent. I was briefly able to read some data but this is inconsistent. Previously FSUIPC was able to log this data for testing purposes. Can you assist?

Thanks again. I am viewing now in OpenOffice.

Thanks John. I have neither Excel or OpenOffice. I use Mac Numbers for my spreadsheets.

Is it possible to have the offsetStatus-vX.X.ods information made available in a more common format (eg. xls, csv or pdf)? I am unable to access the .ods format.

In the FSUIPC7.exe app Options menu, "miscallaneous" should read "miscellaneous".

Thank you for your careful consideration. We will have to disagree.

OK. FSUIPC is looking for files in the installation location and nothing has changed. What was the FSUIPC5 installation location? Regardless, the effect is that FSUIPC6 is looking is a different relative location for these files and this risks causing confusion and adding unnecessary FSUIPC6 files to the add-ons directory. Can I respectfully suggest that the reference to the installation directory be changed to place all files inside with the /FSUIPC6 or /Modules folders? Andrew

Sorry if it is confusing you but it has confused me and my users. I don't understand why the relative install location for .MCRO files has changed between FSUIPC5 (and earlier), namely the enclosing /Modules folder, and FSUIPC6. With the FSUIPC6 add-ons installation, the /FSUIPC6 folder equates directly to the old /Modules and should contain everything related to FSUIPC6 (.dll, .ini, ipcready.lua, etc, .MCRO files and LINDA). Moving the macro files reference to the "installation" directory is wrong. It has broken things.

Hi John Thank you again. Moving the .MCRO to the add-ons directory alongside /FSUIPC6 works as before. With the new P3Dv5 file structure would it not be useful to place all .MCRO files within the /FSUIPC6 folder? This would keep them separate from the many other add-ons that will be installed. EDIT: In the past in the /modules structure the .MCRO were located inside the /modules. This seems to have changed with FSUIPC6.

With FSUIPC6 installed in P3D v5 Addons for P3Dv4 and P3Dv5, a previously working .MCRO installed in /FSUIPC6 is not longer responding the LUA ipc.macro instruction (eg. ipc.macro("FSLTEST2: BAT1)) for aircraft running in P3Dv4.5 (ie. FSLabs A320). I re-recorded some key mouse macros and they proved identical to those I am using. I then ran P3Dv5 and set up a new mouse macro and referenced it using the LUA ipc.macro instruction. This failed to work. FSUIPC6.log contains no data relevant to this problem. I am using FSUIPC 6.0.8 with LINDA 3.2.x. The problem did not exist in FSUIPC5 or FSUIPC4.

FSUIPC6 uninstalled and reinstalled into /modules as suggested. It works fine by redirecting the p3dv5 add-ons/add-ons.xml to /modules/fsuipc6.dll. The dll.xml is unchanged/unused. Many thanks again.

With the alternative P3Dv5 / FSUIPC6 installation using the traditional /Modules with P3Dv5, what is the correct DLL.XML entry? I have been trying the following copied from P3Dv4 but FSUIPC6 is not starting: fsuipcp3d<?xml version="1.0" encoding="UTF-8"?> <SimBase.Document Type="AceXML" version="3,0" id="dll"> <Descr>AceXML Document</Descr> <Filename>dll.xml</Filename> <Launch.Addon> <Name>FSUIPC 6</Name> <Disabled>False</Disabled> <manualload>false</manualload> <Path>C:\P3Dv5\Modules\FSUIPC6.dll</Path> </Launch.Addon> </SimBase.Document> The reason for asking is that I am trying to set up the alternative installation for user support testing.

Hi John Following extensive testing I have established that the contents of 0x3E00 (Flt Sim Path) and 0x3124 (Flt Sim Version) depend on when it is read. LINDA was reading these values on start up whether or not P3D was running. If read with a running P3D the values are correct. Thank you again for your help.

My error I was looking at the wrong offset (3C00 not 3E00). The .dll works on my system. I will pass it on to my user to test. FSUIPC6.log

Further information. With P3Dv4 0x3C00 also appears to point to the current AIR FILE for the loaded aircraft and not the Flt Sim path.