due to a newborn daughter at home
Well ya! Congratulations!
due to a newborn daughter at home
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.
.setText
#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
#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);
#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
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
}
#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);}
If I understood well, .setText is almost as fast than .updateText in 2020.3 (?)
else if ((voltage_mainA > 0) and (voltage_mainA < 27)) {p_dps_sm_sys_summ1.volts_mn1_arrow.setText("down arrow");}
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.
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.
So please use updateText() for all the markers
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
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
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.
I believe it's fast enough to not even require the opt-in
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 ?
Users browsing this forum: No registered users and 3 guests