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.
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.
Can we blank displays via a bespoke event?
Hi,
Would it be possible to add a function call for bespoke events to be able to blank, and restore any modules LED digit display?
I'm trying to write bespoke events to control the MCP-PRO to approximate the displays in an Airbus FCU.
I'm guessing that we aren't able to replace any displayed digit with dashes, so, blanking the displayed digits would be the best alternative.
I would need to blank the SPD, HEADING, V/S and possibly the COURSE fields (not sure how Im going to deal with HEADING/TRACK from the FCU on the MCP-PRO yet)
This facility to programmatically blank displays in bespoke events for GF166 and GF46 might also be useful for avionics bus selections, setting devices to standby etc.
Regards
David
Would it be possible to add a function call for bespoke events to be able to blank, and restore any modules LED digit display?
I'm trying to write bespoke events to control the MCP-PRO to approximate the displays in an Airbus FCU.
I'm guessing that we aren't able to replace any displayed digit with dashes, so, blanking the displayed digits would be the best alternative.
I would need to blank the SPD, HEADING, V/S and possibly the COURSE fields (not sure how Im going to deal with HEADING/TRACK from the FCU on the MCP-PRO yet)
This facility to programmatically blank displays in bespoke events for GF166 and GF46 might also be useful for avionics bus selections, setting devices to standby etc.
Regards
David
Regards
David
David
Comments
Hi David,
You can blank displays using the BLANK Light Actions ( see http://www.pollypotsoftware.org.uk/support/user-guide/user-guide-git/17-concepts/20-light-actions.html ) . If you wanted to control the blanking via Bespoke Events, use a Bespoke Variable to set to 0 or 1 for on/off and then monitor this variable from the BLANK Light Action.
Best wishes
Steve
I think I still might need a bespoke action to blank the display the way I think it needs to work.
The DISPLAY_IAS display is currently set to display the value from BB_FCU_SPD_VALUE (Light/Disp Data)
The decision to blank this display is not dependent on what BB_FCU_SPD_VALUE is, but instead, whether another variable, BB_FCU_SPD_OPEN is set to 1.
So as far as I can work out, if I use the BLANK LIGHT action, looking for a light value of 1, I have to set Light/Disp data to check BB_FCU_SPD_OPEN (which will be either only a 0 or 1) and therefore it wont ever show the value from BB_FCU_SPD_VALUE
So it seems I can have Light/Disp Data field set to one or the other, but not both.
Which is why I was hoping to have the IAS DISPLAY value set by setting BB_FCU_SPD_VALUE and from a Bespoke event trigger, BLANK it when BB_FCU_SPD_OPEN is set to 1 ( or the Bespoke event that causes it to go to 1), and 'unblank' it when BB_FCU_SPD_OPEN is set to 0
Is there another way to achieve this that I havent realized yet?
Regards
David
David
Hi David,
You could create a Start Bespoke Event (http://www.pollypotsoftware.org.uk/support/user-guide/user-guide-git/14-detective/30-the-start-bespoke-event.html) that sets a Bespoke Variable to the BB_FCU_SPD_VALUE if BB_FCU_SPD_OPEN is 0 or sets BB_FCU_SPD_VALUE to -1 if its 1. Add a Sleep Task so that is doesn't consume loads of CPU. Then configure the IAS/MACH display to use the Bespoke Variable using the BLANK light action looking for -1.
Best wishes
Steve
I wrote a START event to attempt to code blanking for the speed and heading values for the FCU, and dividing the value by 100 if MACH is set in the SIM
I didnt think I would need to have to handle a calculation for MACH, as I had set the DISPLAY_IAS light action to IAS_MACH_BLANK, however the value was incorrect by a factor of 100 when the sim switched to using MACH.
The rotary actions of the speed and heading rotaries just simply send the correct event to increase or decrease the LVar values.
Ive set a sleep value of 66 before looping back to the start of the function/event.
Anyway, since writing the code, the lag and response time in GIT has been woeful, so much so that Im now getting freeze/lockups or very very long delays before the DISPLAY values show the correct value. The lack of performance and the lag is so bad, that I dont think Ill be able to continue using it in its present form.
Can you have a look at the code and advise if there is a more efficient way to do 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="66" />
<Task ID="13" Type="Goto" LabelID="12" />
</Event>
Regards
David
David
Hi David,
There is nothing there that should be taking a long time to complete. Try changing your sleep value to 1.
Best wishes
Steve
I have changed the sleep to 1, and whilst this has improved, its still not that usable (poor response)
In comparison, the rotary and display or ALT is controlled via an event, and the value read directly off the LVAR and the performance is very snappy.
So its having to copy the LVAR to a bespoke variable, doing some logic against that and then copying to another bespoke which gets displayed (all via START with a sleep of 1) thats the problem area.
What would be really great if, just for the MCPPRO, some enhancements could be made on the Button/Switches/Rotaries/Displays tab to enhance the displays without the need for my code in START:
What I'm having to do with the code in START is handle:
Given a defined LVAR value ("BB_FCU_HDG_STATUS" = 0 or "BB_FCU_SPD_OPEN" =1 as examples ) blank the display
Given a defined LVAR value,("BB_FCU_SPD_MACH" =1 for example), divide to display a MACH value
With the release on another few airbuses in the FSX/P3D market soon, there could be more MCPPRO users keen to utilize something like this.
Regards
David
David
Hi David,
Looking at your code again, I cannot see why that would be slow. I will need to run some tests and come back to you on it.
Best wishes
Steve
David
I have taken some video showing turning the MCP rotaries, the response on screen in the sim, and the response lights on the GIT status screen. It shows there is some issue with the interaction of the START event and any sim event and LVAR.
Can you send me a private forum message with details on how I might be able to get the video to you if you are interested.
David
I have done further testing to try to narrow down the circumstances that cause slow response in GF displays and the Sim.
I reduced everything back to simple configs, with the idea of progressing one step at a time to identify the root cause.
BASIC:
SPD/HDG/ALT/VS rotaries all call bespoke events sending Sim events to increase/decrease values.
MCP displays linked to Sim LVARs, no START event.
With this setup, the rotaries, GF displays and Sim MCP all update very quickly with no lag, no matter how quickly I turn the rotaries.
This establishes that reacting to the rotaries, sending the Sim Event, and reading the LVARs for the displays are working perfectly.
NEXT LEVEL: - Adding a START Event, with just one line to read one LVAR and assign to a Bespoke Variable. All displays are still set to reading the corresponding Sim LVAR directly, as above.
START Event added, with one line only, with a sleep of 1 in the loop.
<Task ID="15" Type="SetEquiv" Var="Bespoke Var 11" Data="BB_FCU_SPD_VALUE" />
(NOTE: Bespoke Var 11, is not referenced in any other bespoke Event, nor is it tied to any GF display)
Result is no performance impact to HDG/ALT/VS, but significant performance drop when using the SPD rotary.
Increasing the loop sleep to 1200 (1.2 seconds) helps slightly, but still the performance is nowhere like HDG/ALT/VS, and very inconsistent in its response times, and unusable.
CONCLUSION:
It seems to me that the START function with a sleep time of 1ms seems to provide real performance impact IF the LVAR is being read into a Bespoke Variable at the time that the LVAR is being changed in the Sim. When other LVAR values are being changed in the sim, but NOT being read into a Bespoke Variable in the START loop, there is no impact.
Watching the 3 green lights in GIT seems to show that something is blocking or locking up communication between the sim, GIT and GF when an LVAR is being read via a START routine, at the same time as that LVAR is changing within the Sim.
The same scenario exists when a DISPLAY is reading the LVAR directly, whilst the LVAR is changing (via rotary) and yet this causes no performance issues.
Hope this helps to narrow down a possible cause
Regards
David
David
Thanks for your info.
As you can see above, I did an experiment where the only BE command in START, was to read a single LVAR into a Bespoke Variable - thats it.
With a sleep of 1ms (as suggested by Admin a while ago when I first raised this), and the START event running all the time in a loop, there is no perf. issues, UNTIL the LVAR thats being read into the BV is changing in the sim.
If you compare that with the other DISPLAY LEDs for the MCP, which via the GIT panel, are set to read LVars and display the results directly on the MCP unit, even when those LVar values change in the sim, there is no performance issues.
So, when that action, configured via the GIT panel, takes place (IE have GIT read a changing LVar), there is no perf issues.
When a single action via START, is to read in a changing LVAR into a Bespoke Var (and do nothing else with it) there is a huge performance hit.
Ive tried all sorts of different delays, in that test START event (with only 1 action in there) and nothing really helps (Ive tried sleeps starting from 1, and even going up too 1200).
So there is something quite different in reading an LVAR via START event compared with the inbuilt routine when setting a DISPLAY to read an LVAR in the GIT panel.
My preference would be not to have to use START event at all to achieve what I need for Airbus MCPs - but instead have 2 additional features available in the MCP PRO GIT config panel,
and they are:
2 optional conditions that will alter the display, which will be evaluated in order (only the 1st matching condition equaling TRUE would be acted upon)
IE
Cond 1: BLANK DISPLAY when LVARxyz = abc
Cond 2: DISPLAY MACH when LVAR123 = def
The Conditions would be selected from a pre-defined list. The difference between this and what is there presently, is that via these conditions, I could specify a different LVAR that will determine if this logic is TRUE. The current logic in the MCP PRO GIT panel will only evaluate the value of the actual DISPLAY'd LVAR
If 2 optional conditions like this were added to the GIT MCP panel it would mean I wouldn't need complex convoluted events in START to achieve the same thing and hopefully, therefore, not suffer the performance hit I'm getting trying to implement that logic via START
David
This issue should now be resolved in 2.6.0.0
Best wishes
Steve
This issue has been resolved in 2.6.0.0
The performance reading/setting vars via START is excellent and there is no lag/delay in updating displays.
Superb!
Many thanks
David