Board index FlightGear Development Spaceflight

Space Shuttle - Display adjustments (PFD, DPS, HUD,...)

Discussion about development and usage of spacecraft

Re: Space Shuttle - Display adjustments (PFD, DPS, HUD,...)

Postby wlbragg » Tue Oct 20, 2020 4:21 am

due to a newborn daughter at home


Well ya! Congratulations!
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7588
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: Space Shuttle - Display adjustments (PFD, DPS, HUD,...)

Postby GinGin » Sun Oct 25, 2020 6:47 pm

Antenna simulator

Image
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Display adjustments (PFD, DPS, HUD,...)

Postby GinGin » Fri Oct 30, 2020 12:08 am

I really started the SM part.
And I decided to go through the symbols that indicate failures.

Basically, a L or H is the Lower/Higher value from a transducer ( hard limit)
A down arrow or up arrow might be a broken sensor/valve/etc or a value that is becoming too High/Low.

I had to crosscheck 2 or 3 different source of references to decide which one will be usefull or not for FG.
Mainly done with the research, I finished with the Sum up displays.



Image

Image



An example of how handy it is.

Apu 1 is started.
Apu 2 and 3 not ( Lower value for the speed, and fuel full)
Recirc pump number 3 did not activate, as the hyd pressure is low in the lines
Water in Water Boiler is full

One water pump is down ( L), other one in standby ( 23 down arrow indicating a low value, but not the minimum)
One Freon loop is lost ( first one, 0L)

Temperature of Freon after cooling cycle is OK ( no yellow stuff next to evap out T)

So pretty interesting for a quick sum up of Orbiter state

Image





A bit more worrisome with the next example.

Rapid loss of pressure in the cabin ( PRESS 12.31 down arrow)

Shortcut in elec system 2 and 3 ( many down arrows) and High parameters for the fuel cells 2 and 3 ( High Amps, and stack temp)


Image


Shutdown of the two fuel cells.
No more shortcut.
But the FC 1 has to take all the Orbiter Load, hence the high FC temperature ( 220 up arrow)

A lot of down arrows for FC 2 and 3 as they were shutdown, so many parameters are low, but associated with a powerdown

Image
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Display adjustments (PFD, DPS, HUD,...)

Postby GinGin » Sat Oct 31, 2020 11:14 am

Incorporated the very small differences of the system sum up when dispplayed by the BFS

IMU fan pressure difference instead of IMU fan activation state for sum up 1 ( plus some parameters that vanish)

Image



A bit more insight on APU ( Gas Generator temperature and monitoring of high EGT temp when APU ran at high speed) plus some very minor path differences for sum up 2

Image
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Display adjustments (PFD, DPS, HUD,...)

Postby Thorsten » Sat Oct 31, 2020 12:32 pm

A word of caution about the range checks and indicators. The reason that we have so few of them implemented is not so much that I didn't get around to do it, but that I had serious performance concerns.

In a straightforward implementation, they would basically at least triple the performance drain of every display (fetching the limits checking against the limits, selecting the appropriate symbol to display and write that to the canvas text element).

Now, canvas is faster than it was a few years ago, and we now have more suitable tools (like updateText() instead of setText()) as well as the possibility to use a Nasal data structure for the limit values - so I believe it is doable these days - but this is one of the situations where it really has to be implemented in a particular way to not cause trouble.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle - Display adjustments (PFD, DPS, HUD,...)

Postby GinGin » Sat Oct 31, 2020 4:22 pm

Thorsten wrote in Sat Oct 31, 2020 12:32 pm:A word of caution about the range checks and indicators. The reason that we have so few of them implemented is not so much that I didn't get around to do it, but that I had serious performance concerns.




I was thinking about that.
I made a test with only the two sys sum up pages for now, and tried to just feed parameters where there is an interest to have those indicators.
It is easy code wise to revert to "previous mode" by just putting some # before the test indicator in the concerned nasal file

I was also considering to put it under a conditionnal that would be activated in space shuttle option ( like for detailled cockpit).
Something like basic SM display or advanced one for faster rig.

If the concerned dps page is not opened in on of the MEDS screens, is there stillall the calculations of the corresponding nasal file ?

So far, I used
Code: Select all
.setText


I saw this on wikipedia:
If I understood well, .setText is almost as fast than .updateText in 2020.3 (?)
I can revert to .enableUpdate and .updateText.

Image



So far, it looks like that:

I call all the arrow space:

Code: Select all
#Failure Arrow indicators // Yellow Color (Parameters that can reach their limits L or H //  valve state )

p_dps_sm_sys_summ1.volts_fc_arrow = device.svg.getElementById("p_dps_sm_sys_summ1_volts_fc1_arrow"); 
p_dps_sm_sys_summ1.volts_fc2_arrow = device.svg.getElementById("p_dps_sm_sys_summ1_volts_fc2_arrow");
p_dps_sm_sys_summ1.volts_fc3_arrow = device.svg.getElementById("p_dps_sm_sys_summ1_volts_fc3_arrow");

p_dps_sm_sys_summ1.volts_mn1_arrow = device.svg.getElementById("p_dps_sm_sys_summ1_volts_mn1_arrow");
p_dps_sm_sys_summ1.volts_mn2_arrow = device.svg.getElementById("p_dps_sm_sys_summ1_volts_mn2_arrow");
p_dps_sm_sys_summ1.volts_mn3_arrow = device.svg.getElementById("p_dps_sm_sys_summ1_volts_mn3_arrow");

p_dps_sm_sys_summ1.volts_ess1_arrow = device.svg.getElementById("p_dps_sm_sys_summ1_volts_ess1_arrow");
p_dps_sm_sys_summ1.volts_ess2_arrow = device.svg.getElementById("p_dps_sm_sys_summ1_volts_ess2_arrow");
p_dps_sm_sys_summ1.volts_ess3_arrow = device.svg.getElementById("p_dps_sm_sys_summ1_volts_ess3_arrow");

etc



I put then under a subgroup in the svg, to just call one time that group for the color

Code: Select all
#All arrows in a group to have just one line for .setcolor

p_dps_sm_sys_summ1.arrow_group = device.svg.getElementById("p_dps_sm_sys_summ1_arrow_group");
p_dps_sm_sys_summ1.arrow_group.setColor(1, 1, 0);




And then I put the logic for indicators, here for Main Bus

Code: Select all
#Main bus volts lower indicator (L)

if (voltage_mainA == 0) {p_dps_sm_sys_summ1.volts_mn1_arrow.setText("L");}
else if ((voltage_mainA > 0) and (voltage_mainA < 27)) {p_dps_sm_sys_summ1.volts_mn1_arrow.setText("down arrow");}
else if (voltage_mainA > 32) {p_dps_sm_sys_summ1.volts_mn1_arrow.setText("up arrow");}
else {p_dps_sm_sys_summ1.volts_mn1_arrow.setText("");}

same for mainB and mainC
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Display adjustments (PFD, DPS, HUD,...)

Postby GinGin » Sat Oct 31, 2020 7:20 pm

I quickly tried the SM detail level based on the dps realism option.

A global variable at the top of sm nasal file:

Code: Select all

var sm_simulation_level = getprop("/sim/config/shuttle/sm-detail-level");

.
.
.
.
.
#at the end of the nasal file to have all the previous variables available

if (SpaceShuttle.sm_simulation_detail_level == 1)
  {
   #All the indicators
if (voltage_mainA == 0) {p_dps_sm_sys_summ1.volts_mn1_arrow.setText("L");}
else if ((voltage_mainA > 0) and (voltage_mainA < 27)) {p_dps_sm_sys_summ1.volts_mn1_arrow.setText("down arrow");}
else if (voltage_mainA > 32) {p_dps_sm_sys_summ1.volts_mn1_arrow.setText("up arrow");}
else {p_dps_sm_sys_summ1.volts_mn1_arrow.setText("");}

etc

}




I will try that deeper, but it seems to be a good solution to at least leave the choice to the user (?)


Image
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Display adjustments (PFD, DPS, HUD,...)

Postby GinGin » Sat Oct 31, 2020 9:51 pm

That seems to work well.

Code: Select all
#SM realistic option with indicators

if (SpaceShuttle.sm_simulation_detail_level == 1)
{

      p_dps_sm_sys_summ1.arrow_group.setVisible(1);

      #Fc Amps higher limit indicator (H)

   if (fc_amps1 > 499) {p_dps_sm_sys_summ1.amps_fc1_arrow.setText("H");}
   else if (fc_amps1 == 0) {p_dps_sm_sys_summ1.amps_fc1_arrow.setText("L");}
   else {p_dps_sm_sys_summ1.amps_fc1_arrow.setText("");}

   if (fc_amps2 > 499) {p_dps_sm_sys_summ1.amps_fc2_arrow.setText("H");}
   else if (fc_amps2 == 0) {p_dps_sm_sys_summ1.amps_fc2_arrow.setText("L");}
   else {p_dps_sm_sys_summ1.amps_fc2_arrow.setText("");}

   if (fc_amps3 > 499) {p_dps_sm_sys_summ1.amps_fc3_arrow.setText("H");}
   else if (fc_amps3 == 0) {p_dps_sm_sys_summ1.amps_fc3_arrow.setText("L");}
   else {p_dps_sm_sys_summ1.amps_fc3_arrow.setText("");}

 etc
}

else {p_dps_sm_sys_summ1.arrow_group.setVisible(0);}




No indicators

Image


Indicators

Image
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Display adjustments (PFD, DPS, HUD,...)

Postby Thorsten » Sun Nov 01, 2020 10:59 am

If I understood well, .setText is almost as fast than .updateText in 2020.3 (?)


I don't think that was ever merged (or at least I objected to merging this). updateText() is an optimization for the case that you need to change the text rarely, it uses more memory and CPU cycles than setText() in the case you do update. The proposal was to make updateText() the default case (in addition to storing more structure) - my objection is that we should be optimizing to the particular use case, not do shotgun attempts in defaults (in the event, I admit the proposed change is not dramatically wasteful, but still it is unnecessarily wasteful).

So please use updateText() for all the markers.

Otherwise this

Code: Select all
else if ((voltage_mainA > 0) and (voltage_mainA < 27)) {p_dps_sm_sys_summ1.volts_mn1_arrow.setText("down arrow");}


is quite okay performance wise (fetch voltage_mainA only once from property, then use the Nasal variable to compare). If the limits never change, at least I am fine with hard-coding them in the way you have done (there's also the idea around in coding that hard-coding numbers that way in the code should be avoided and rather variables like lower_voltage_limit should be used).

Anyway, in case you need runtime variable limits (not sure if there is a case), do not encode them in properties but rather use a Nasal data structure for that.

And that's all - if you do that and do updateText(), I believe it's fast enough to not even require the opt-in. :D
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle - Display adjustments (PFD, DPS, HUD,...)

Postby Hooray » Sun Nov 01, 2020 5:26 pm

Thorsten wrote in Sat Oct 31, 2020 12:32 pm:A word of caution about the range checks and indicators. The reason that we have so few of them implemented is not so much that I didn't get around to do it, but that I had serious performance concerns.

In a straightforward implementation, they would basically at least triple the performance drain of every display (fetching the limits checking against the limits, selecting the appropriate symbol to display and write that to the canvas text element).

Now, canvas is faster than it was a few years ago, and we now have more suitable tools (like updateText() instead of setText()) as well as the possibility to use a Nasal data structure for the limit values - so I believe it is doable these days - but this is one of the situations where it really has to be implemented in a particular way to not cause trouble.


FWIW, we did have this discussion several times over the years (see Canvas display property I/O) - basically, if people run into potential performance issues like these, it's best to report so via the issue tracker. In general, extending the C++ code to support "Nasal-less" update() routines would not be very complicated, and it would not just benefit a single aircraft/use case.

For instance, depending on the concrete API needed here, it would be possibly to use property rules to encode range checking, and instead of building/updating text strings in Nasal space, Canvas.Text could be easily extended to support sprintf-style format strings that may reference an arbitrary number of properties (and conversions) that are then checked/fetched in C++ space.

At that point, we'd end up with a canvas (element( that has its own instance of the FGAutopilotXML/PropertyRules system, which would be merely set up and configured from Nasal, but most of the string building, and property conversion/concatenation could be delegated to C++ space too: search.php?st=0&sk=t&sd=d&sr=posts&keywords=sprintf+canvas

Once that machinery is in place in the underlying C++ code, MFD frameworks like Richard's could easily make use of it, so that aircraft-level modules (shuttle, F15 etc) would automatically benefit.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Space Shuttle - Display adjustments (PFD, DPS, HUD,...)

Postby GinGin » Sun Nov 01, 2020 6:20 pm

updateText() is an optimization for the case that you need to change the text rarely, it uses more memory and CPU cycles than setText() in the case you do update.


Alright, I see.
Is their a rule of thumb behind "rarely" ? Like a minimum of changes per seconds maybe (?)

So please use updateText() for all the markers


No problem, I will do that.
Do I need to put every indicator svg elements with a .enableUpdate(), or can I just apply .enableUpdate() to the sub svg group where I put all the indicators (like I did with the .setColor above) ?



fetch voltage_mainA only once from property, then use the Nasal variable to compare


I did that.
I get rid of all the getProp() when I will have to use more than once the variable.


If the limits never change, at least I am fine with hard-coding them


No, it does not change. ( Some slight differences sometimes between BFS and PASS one, but I take a mean 95% of the time)


the idea around in coding that hard-coding numbers that way in the code should be avoided and rather variables like lower_voltage_limit should be used



You mean I should not put numbers, but create global variables with those limits to be reused in others nasal dps file ?

Like

Code: Select all
Var Fc_lower_volts_limit = 0; ( at the top of a nasal file ?)

SpaceShuttle.Fc_lower_volts_limit then to call it ?




Anyway, in case you need runtime variable limits (not sure if there is a case), do not encode them in properties but rather use a Nasal data structure for that.


Ok, I will.
There are some, like the stack temp high limit, which depends on Kw.
But I just take a mean, and it works fine like that.


I believe it's fast enough to not even require the opt-in


Lets try like that.
I will keep the opt in for now, as it is fast to remove, and put anyway all the indicators at the end of the nasal files to have access to all the previous variables fetched.
Thanks for the advice.
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Display adjustments (PFD, DPS, HUD,...)

Postby Hooray » Mon Nov 02, 2020 3:36 pm

GinGin wrote in Sun Nov 01, 2020 6:20 pm:
the idea around in coding that hard-coding numbers that way in the code should be avoided and rather variables like lower_voltage_limit should be used

You mean I should not put numbers, but create global variables with those limits to be reused in others nasal dps file ?


For the full background, refer to: magic numbers.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Space Shuttle - Display adjustments (PFD, DPS, HUD,...)

Postby GinGin » Tue Nov 03, 2020 5:59 pm

Hooray wrote in Mon Nov 02, 2020 3:36 pm:
For the full background, refer to: magic numbers.


Thank you, interesting reading.
I will think to it then for variables that I might used in 3 or 4 different files.
I put always some annotations though for other code readers, to know what "lonely" numbers are doing there.

Is there a performance gain in Nasal to fetch numbers into global variables if it is not used in many files ?
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Space Shuttle - Display adjustments (PFD, DPS, HUD,...)

Postby Thorsten » Tue Nov 03, 2020 6:29 pm

As I said, it's just a question of style - I'm fine with what you're doing, so just don't sweat it. :D
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle - Display adjustments (PFD, DPS, HUD,...)

Postby GinGin » Fri Nov 06, 2020 10:37 pm

A bit of progress this week, going for the .updatexText and better utilisation of already existing variable.

Some "easy to convert" dps pages



Image

Image

Image


Almost finish with the electric displays

Image


While going through the System Management indicators thing, I am updating the cws with new fault messages, in relation with what is available in FG failure wise

Here is a simple example of an AC shortcut in circuit 1
In red, Undervolt in the main bus with the associated values (Low Main bus 1, fuel cell output power1, high amps due to short etc)
In pink, Ac 1 short and overload confirmed by the datas we have in Spec 67
Plus a list of failures associated with the loss of one electric redudance ( some heaters, fans etc)

A simple failure leads to a lot of small consequences, easily observable with indicators and fault messages pointing towards where we have to look for incoming troubleshooting

Image


Quite same kind of failure but with the BFS system management dps and fault messages

Image
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

PreviousNext

Return to Spaceflight

Who is online

Users browsing this forum: No registered users and 3 guests