APU Bleed start engines Project Magenta 738

[jr2mey]

Hello all,

 

Is there anyone who is using Project Magenta 738 with MSFS2020?  I am trying to find out how I can write a script to bleed start my engines.  This is the only hickup so far in trying to get my simulator up and running in MSFS2020.  I have included a lua script that is my attempt at trying to get my Project Magenta 738 started by way of APU...  Why have a simulator if all you can do is press Ctrl-E..  LOL

I have used all of the offset settings for offset 0B50 and none of them get my engines turning.

 

I see that there is some working but not yet added event controls associated with engine bleed and APU bleed.

BLEED AIR APU

BLEED AIR ENGINE 

APU BLEED PRESSURE RECEIVED BY ENGINE

  DO I need to have these events working for my 737 to start up?

 

Also, when looking at my script, please know that I am learning how to write LUA.

 

Kind Regards,

James 

A_engStarts.lua

[John Dowson]

13 hours ago, jr2mey said:

Is there anyone who is using Project Magenta 738 with MSFS2020?

Not me...! I have added Project Magenta to the tile of your post to (hopefully) attract any other PM users... Have you tried asking on PM support?

13 hours ago, jr2mey said:

I have used all of the offset settings for offset 0B50 and none of them get my engines turning.

Writing to this offset sends the Bleed Air Source Control Inc/Dec controls - maybe that is not working in the PM 738?

13 hours ago, jr2mey said:

I see that there is some working but not yet added event controls associated with engine bleed and APU bleed.

BLEED AIR APU

BLEED AIR ENGINE 

APU BLEED PRESSURE RECEIVED BY ENGINE

  DO I need to have these events working for my 737 to start up?

I don't know.... Where do you see these controls? Do you know the associated control/event numbers? I could look into adding them if needed...Probably best to talk to Project Magenta / Enrico and get them to contact me for adding any new controls.

13 hours ago, jr2mey said:

Also, when looking at my script, please know that I am learning how to write LUA.

I can't really comment on your lua script as I don't know much about the PM offset areas (0x5400 -5FFF) - I have no information on what these hold. However, it does seem a little strange that you are only using event.offsetmask and event.offset functions, all calling the same function. So the function is only called when something triggers one of those offset to change - what is doing this?

John

[jr2mey]

48 minutes ago, John Dowson said:

I can't really comment on your lua script as I don't know much about the PM offset areas (0x5400 -5FFF) - I have no information on what these hold. However, it does seem a little strange that you are only using event.offsetmask and event.offset functions, all calling the same function. So the function is only called when something triggers one of those offset to change - what is doing this?

John

Good Morning John...

What I am attempting to do with my LUA script is to take the triggering of the overhead switches from PM and translate them over to MSFS2020 starting sequence. Apparently the PM aircraft operates under legacy. So I have learned that I was having an issue at how the 0B50 offset differs if your calling an airbus apu start or another jet aircraft apu start.  I guess airbus is special.. LOL

Great news though, I got her to start correctly via the APU bleed. After I sorted out the 0B50 offset issue, I just needed to, for what ever reason, use IPC.Control (66300,2) then follow up with IPC.control (66301) to command the engine (2) to start.  I don't know why Microsoft has me do this, but it works!

For the last ten years, I have always been use to working with FSUICP and offsets without an issue.  Now I am looking at having to learn HTLM, Lua and what the darnation LVARS and HVARS are... LOL

Thank you for continuing to develop FSUICP... great great product!

 

James

[jr2mey]

1 hour ago, John Dowson said:

I don't know.... Where do you see these controls? Do you know the associated control/event numbers? I could look into adding them if needed...Probably best to talk to Project Magenta / Enrico and get them to contact me for adding any new controls.

Sorry John, I forgot to tell you that where I got those bleed control was in your FSUICP7 Offset status, page 118.

 

James

[John Dowson]

39 minutes ago, jr2mey said:

Great news though, I got her to start correctly via the APU bleed. After I sorted out the 0B50 offset issue, I just needed to, for what ever reason, use IPC.Control (66300,2) then follow up with IPC.control (66301) to command the engine (2) to start.  I don't know why Microsoft has me do this, but it works!

Ok, glad you got it working. Strange that you need a parameter of 2 to the 66300 control though, which is Toggle Starter1 - doesn't this work without that parameter?

34 minutes ago, jr2mey said:

Sorry John, I forgot to tell you that where I got those bleed control was in your FSUICP7 Offset status, page 118.

Ah! Then they are MSFS simvars (or A type variables), not controls, and nothing to do with PM.
I could add those to FSUIPC7 offsets. However, I am currently working on functionality to let the user add any of these additional simvars to a free (for user use) offset.
This should be available in the next FSUIPC7 release, hopefully sometime next week.

John

[jr2mey]

45 minutes ago, John Dowson said:

Ok, glad you got it working. Strange that you need a parameter of 2 to the 66300 control though, which is Toggle Starter1 - doesn't this work without that parameter?

So, what I found when I use just the (66301) to attempt starting engine (2) all I get is a spin up and no N2 nor fuel flow.  I get the audible sound of an engine spinning up but no actual engine start is occurring.  I found the event (66300,2) from the FSUICP event logging console when having the auto start start the engines.  Now, when I put in the ipc.control (66300,2) before the ipc.control (66301), she fires off like a wild banshee. I am sure it is my plane having issues with the start procedure.  LOL

 

50 minutes ago, John Dowson said:

However, I am currently working on functionality to let the user add any of these additional simvars to a free (for user use) offset.
This should be available in the next FSUIPC7 release, hopefully sometime next week.

That is outstanding sir!  Look forward to it.

Thank you again,

James

[John Dowson]

On 2/17/2022 at 7:05 PM, jr2mey said:

 

On 2/17/2022 at 6:09 PM, John Dowson said:

However, I am currently working on functionality to let the user add any of these additional simvars to a free (for user use) offset.
This should be available in the next FSUIPC7 release, hopefully sometime next week.

That is outstanding sir!  Look forward to it.

This is now implemented in the attached beta version if you would like to try. No documentation yet - I'll add that and release officially sometime next week.
To add a simvar to a free offset, create a file called myOffsets.txt in your FSUIPC7 installation folder. The format of each entry is:
     offset, size, simvar, type, units [, w]
(where w signifies it is also writeable and is optional). For the units, check the MSFS documentation (use what the documentation states for that simvar, or any compatible unit if you want it converted). The type should be one of the following:
          I32 - 32-bit integer
          I64 - 64-bit integer
          F32 - 32-bit floating point number
          F64 - 64-bit floating point number
          S8,S32,S64,S128,S256,S260 - strings with the number indicating length
          LLA - 3* 32-bit floats (Latitude/Longitude/Altitude)
          XYZ - 3 * 64-bit doubles (values representing x,y,z positions)
(NB. I could extend these if needed).
The size should match the type/units, and will be the size used by the offsets. This can be smaller than the type, e.g. an I32/Bool ot I32/Enum can fit in 1 byte - you don't need 4 bytes (32 bits).

Note also that the offset needs to be bound to the size. This means that if the size is 8, the last offset digit needs to be 0 or 8, if the size is 4, the last offset digit needs to be 0, 4, 8 or C, etc (but not for string types).

Lines starting '//' are ignored.

Here is an example myOffsets.txt file:

Quote

// offset, size, simvar, type, units [, w]
0x66C0, 1, ELECTRICAL MASTER BATTERY:2,I32, Bool, w
0x66C1, 1, ATC HEAVY, I32, Bool, w
0x66C2, 2, COM VOLUME, I32, Percent
0x66C4, 1, COM SPACING MODE, I32, Enum, w
0x66C6, 2, TRANSPONDER CODE:1, I32, BCO16, w
0x66C8, 2, TRANSPONDER STATE, I32, Enum, w

Check your FSUIPC7.log file when using this, it should report any errors.

John

FSUIPC7.exe

[Scotfleiger]

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

[John Dowson]

11 hours ago, Scotfleiger said:

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

It is the size if the simvar as held in the offset table, the second number, that you need to change, i.e.

// offsets, size, simvar, type, units [, w]
0x66C0, 2, EXTERNAL POWER AVAILABLE, I32, Bool
0x66C2, 1, EXTERNAL POWER ON, I32, Bool

I32 is the type of the simvar as received from simconnect and maps to the simconnect datatype SIMCONNECT_DATATYPE_INT32, so is actually 4 bytes. It is up to you to determine what values the simvar holds, and size the offset accordingly.

John

[Scotfleiger]

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

[John Dowson]

What do you see when you list the lvars from the FSUIPC Add-ons->WASM->List Lvars menu item?
 

1 hour ago, Scotfleiger said:

These are seen with FSUIPC7 List Lvars and my scan with LINDA using ipc.GetlvarName().

What ids are you using when using that function? Maybe they are out of range? Of course, if out of range then nil should be returned...
Maybe you can log the id with the name, and compare to the list from FSUIPC.

[John Dowson]

Also, please try with the latest build, attached. This is the next version I will be releasing, hopefully over the weekend. Just need to do a bit more testing and update the documentation. This version is built against the latest MSFS SDK, v0.17.0.0.

John

FSUIPC7.exe

[Scotfleiger]

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

[Scotfleiger]

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.

 

[John Dowson]

3 hours ago, Scotfleiger said:

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.

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. I made this change as lua scripts that depend on hvars/lvars wouldn't have them available when starting. The ipcInit.lua is started earlier, as soon as the simconnect connection is obtained, but the lvars/hvars will not be available at this time. I will make this clear in the documentation.

As for those strange lvars, they are the same in the FSUIPC log file as you get when scanning via lua, so they seem to be valid lvars. Maybe they are related to that plugin you mentioned...

John

[Scotfleiger]

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

[John Dowson]

17 minutes ago, Scotfleiger said:

Something has definitively been broken.

There was a correction to what I assumed was dodgy code when offsets not in the internal FSUIPC offset table (such as the ones allocated to Linda) were written to, which is most probably the cause. Can you try the attached.

John

FSUIPC7.exe

[Scotfleiger]

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.

 

[John Dowson]

Strange...can you try the attached (haven't changed the version): FSUIPC7.exe

[Scotfleiger]

5 minutes ago, John Dowson said:

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

That's working again. Thank you.

[John Dowson]

Ah, ok. Interesting....

John

[John Dowson]

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

John

FSUIPC7.exe

[Scotfleiger]

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.

[John Dowson]

👍

Thanks!