Most of the commonly reported issues and questions are answered in the Frequently Asked Questions (FAQ) option under the Support menu of this website.
*** PLEASE NOTE ***
Your forum account is not the same as the account used in the shop. They are completely separate accounts.
1st December: A new version of the GoFlight Interface Tool for MSFS is now available.
12th November: A new version of the GoFlight Interface Tool for X-Plane is now available.
6th June: A new version of Virtual Flight Sim Hardware is now available (huge update)
21st November: A new version of the GoFlight Interface Tool for FSX/FSXSE/P3D is now available.

Problems with read/write FSUIPC offsets

Hi,

Can anyone help with examples of how to read and write an FSUIPC offset in a bespoke event please?

I thought I could work out how to do this.

I first attempted to read an offset and store the value in a BespokeVariable.

in my START Bespoke Event, I added
 Bespoke Var 0 = ReadMemSB(7b91)
into the loop that manages my other MCPPRO values.

I then set my MCPPRO DisplayCourseLeft Light/DispData to Bespoke Var 0

I enabled/displayed MODE-C in vPilot (which changes offset 0x7b91) however I didnt see any change in the Left Course Value

I then attempted to set or change the offset via a T8 switch calling Bespoke Events, which ran either:
SetMemSB 7b91 = 0
or
SetMemSB 7b91 = 1

but neither of these events seemed to make any change to offset 7b91 value

I kept an eye on that offset in FSUIPC via the Monitor IPC in the toolbar, and could see the value changing when I used vPilot, but not changing when I tried to change the value via GIT.

What am I doing wrong?
I'm sure its something really simple but I cant seem to work it out.

Regards
David



Regards
David

Comments

  • edited September 2016
    It may be a permissions issue? Have you tried running GIT as admin or disabling UAC? Just a guess...

    EDIT: yeah David i just tested this on my system too and it was not working, ran GIT as admin and now it can change the value. Give it a try. 
    Steve McNitt
  • Thanks for the heads-up on that issue. I'll see if I can work around the security issue in a later release.

    Best wishes

    Steve

  • Running GITS as Admin has temporarily fixed the problem - excellent - thanks.

    Running as Admin seems to have fixed one other issue also - I was getting poor response time from my rotaries via a Bespoke Event ( I think )
    The only issue I have left is the absolutely shocking performance from rotaries/displays I have to control via the START event loop - its bordering on almost unusable

    Im desperate for a better solution for the MCPPRO to simulate the Airbus FCU (begging for a better solution - please please please :-) )
    Regards
    David
  • How long is your sleep in start?
    Steve McNitt
  • The Start Event runs on its own thread and will run at the full speed of your PC if you let it and your CPU usage will soar to 100% - hence why you need to add a Sleep Task. The issue lies else where! Why are you doing the updates on the Start Event, can they not be added to separate Bespoke Events and called directly from the hardware? If not, post your code for me to look at.

    Best wishes

    Steve

  • The code I'm having to use is to emulate  the Airbus FCU display on the MCPPRO

    Specifically:

    A particular LVAR indicates when the display should display decimal (MACH), and therefore divide the LVAR value by 100 when set
    A particular LVAR flags when the display should be blank (managed mode)


    The current code looks like this:

        <Event Name="START" ID="76" Backgnd="False">
                    <Task ID="12" Type="Label" Name="SET_SPEED" />
                    <Task ID="15" Type="SetEquiv" Var="Bespoke Var 11" Data="BB_FCU_SPD_VALUE" />
                    <Task ID="7" Type="If" Var="BB_FCU_SPD_MACH" Operator="EQUALS" Value="1" />
                    <Task ID="16" Type="SetDiv" Var="Bespoke Var 11" Data="100" />
                    <Task ID="26" Type="If" Var="BB_FCU_SPD_OPEN" Operator="EQUALS" Value="1" />
                    <Task ID="19" Type="Set" Var="Bespoke Var 11" Data="-1" />
                    <Task ID="20" Type="SetEquiv" Var="Bespoke Var 10" Data="Bespoke Var 11" />
                    <Task ID="21" Type="Label" Name="SET_HDG" />
                    <Task ID="22" Type="SetEquiv" Var="Bespoke Var 21" Data="BB_FCU_HDG_VALUE" />
                    <Task ID="27" Type="If" Var="BB_FCU_HDG_STATUS" Operator="EQUALS" Value="0" />
                    <Task ID="24" Type="Set" Var="Bespoke Var 21" Data="-1" />
                    <Task ID="25" Type="SetEquiv" Var="Bespoke Var 20" Data="Bespoke Var 21" />
                    <Task ID="11" Type="Sleep" Duration="1" />
                    <Task ID="13" Type="Goto" LabelID="12" />
                </Event>

    IE I need extra control to determine what LVAR flag should dictate when the display goes blank (other than the display value LVAR) and
    extra control to determine when a MACH decimal should be displayed by dividing the display value LVAR by 100, when said flag is set


    Regards
    David

    Regards
    David
  • In the MCP there is a "mach or blank" setting that may cut down on some of your logic
    Steve McNitt
  • Hi Steve,

    Sadly thats not possible.

    blank, like many of the other options, relies on setting the display value to match a certain criteria.
    In the case of this A320, the LVAR which the display value shows doesnt change if the FMGS is put into managed mode when its supposed to go blank - instead its a different LVAR that determines if its in managed mode (BB_FCU_SPD_OPEN) and therefore its dependent on that LVAR (0 or 1) that dictates if the airspeed display is blank or not.
    When it displays MACH instead, its value is MACH * 100 and therefore again, doesnt trip GIT into thinking its in MACH mode.  This mode can be evaluated by a different LVAR, BB_FCU_SPD_MACH (0 or 1).

    Likewise for HDG, there is another LVAR that determines if the display should be blank or not (0 or 1)
    Regards
    David
  • In the case of the heading use only 1 bespoke variable and set it to a number outside of the normal heading range when you evaluate the blanking variable it is blank (ie 361) then in your mcp heading display set the blank value to 361 this will make it show the heading normally and blank when it goes out of range. It took me a little bit to figure it out too, ill see if i can dig out an example of how i handled it on the T7 which is very similar to what you are doing.
    Steve McNitt
  • edited September 2016
    Thats what I am doing here in this part of the code:

                    <Task ID="21" Type="Label" Name="SET_HDG" />
                    <Task ID="22" Type="SetEquiv" Var="Bespoke Var 21" Data="BB_FCU_HDG_VALUE" />
                    <Task ID="27" Type="If" Var="BB_FCU_HDG_STATUS" Operator="EQUALS" Value="0"/>
                    <Task ID="24" Type="Set" Var="Bespoke Var 21" Data="-1" />

    "BB_FCU_HDG_VALUE" LVAR is read only from the sim, which is why I have to copy to Bespoke 21, and set 21 to -1 if its supposed to be blank (if BB_FCU_HDG_STATUS =0 (IE managed)) Ive set the DISPLAY to blank if -1

    I have to do the same for the SPD, with the added complexity of also dealing with MACH



    Regards
    David
  • So correct me if I'm wrong, in managed mode you pull the knob out or push it in I can't remember right? 

    Why not make it work like that on the MCP by  turning the push function of the IAS dial into a toggle that in 2 modes modifies the same bespoke variable for output to the  IAS display, so that when you are in managed mode you do the math behind the scenes to output a decimal value or a blanking number.   and in the other mode you output IAS or a blanking number ? 

    or does it not work that way? I'm a bit rusty on the airbus stuff..
    Steve McNitt
  • The airbus has managed and open modes. On the real FCU, you push the rotary button to go into managed mode, and pull to go into open. For altitude for example, you can dial up your next FL and when you are ready to climb/descend, you can push to go into managed climb/decent, or pull for an open climb/decent. When in managed mode, the display will blank and a round dot appears next to the function (except for ALT, it never blanks). When in Open mode, the dot disappears and the value is displayed (unless you are dialing up your next selection)

    On the MCPPRO its not set up like that so I have had to adapt it, and invert the functions.
    When I want to go into managed mode, I press the SPEED or HDG SEL or ALT HLD buttons, and the button LED lights up (replicating the round dots). To go into Open mode, I press the IAS, HEADING OR ALT rotary. (In the real FCU pushing the rotary goes into managed and not open, but it was counter intuitive because IM also using the button LEDs).

    Each of the buttons, rotary and push rotary have bespoke events.
    Regards
    David
  • So, lets take the HDG function.

    Read only LVAR "BB_FCU_HDG_VALUE" holds the current HDG value
    Read only LVAR "BB_FCU_HDG_STATUS" holds status of MANAGED (0) or OPEN (1)

    Left/right turns of the HDG rotary call specific A/C events to increase or decrease the HDG value, which is reflected in the "BB_FCU_HDG_VALUE".

    The HDG display cant directly read from this because, at some point Ill need to blank it.
    The current GIT settings only let me specify a particular value that is used to feed the HDG dipslay to blank it.  The problem is this value will only ever be 000-359 and not a value I can directly manipulate.
    So I have to constantly read "BB_FCU_HDG_VALUE", copy it to a Bespoke Variable, where I can now manipulate, and set it to -1 IF i find "BB_FCU_HDG_STATUS" is set to 0 (Managed mode).

    As the 'bus might kick me out of managed mode, I have to constantly read the 2 BB LVARS as I cant guarantee it will only ever switch between the 2 modes on my actions alone.
    Regards
    David
  • I looked at your video now I can see what is happening.

    I had a similar issue before on a profile. I'll look when i get home but it seems you need to put a small sleep in between your bespoke events in your Start because GIT will send so fast that it will flood the input and the sim will discard a lot of it. Try 20ms sleep between BEs in Start . Also bump up your sleep at the end to about 80. I know it sounds backwards adding delays when it's lagging.

    There are also sliders in the program that deal with with timings but not all of them apply. You have to read the description to see if it applies.
    Steve McNitt
Sign In or Register to comment.