CRJ700 family goes canvas

[D-ECHO]

@tdammers, oops didn't realize the access hat been set to read-only. All team members should have "Admin" rights now

[tdammers]

Cool, thanks!

[jsb]

Finally I managed to upload a release candidate to https://github.com/d-jsb/CRJ700-family
Lots of things have changed, many details were added so don't be frustrated if things are not as easy or obvious as before. Most outstanding upgrade is the canvas based EFIS (PFD, MFD, EICAS). You can pop out each screen into a window. The display selectors on the sidepanels and pedestal panel are also implemented.
Updating the documentation is an open issue, the checklists and one or two tutorials should be quite ok, but I did not verify them lately...
FDM got some overhaul, the approach config used wrong weights leading to much too high lift on landing - should be better now but you need to adjust the trim before takeoff and you really have to pull at Vr to rotate.

Have fun

[legoboyvdlp]

I appreciate seeing the jsbsim FDM

There is a nasal error, on the off-chance you are not aware of it:

Code: Select all

Nasal runtime error: undefined symbol: update_pass_signs
  167.05 [ALRT]:nasal        at C:/Users/redpa/Documents/FlightGear/Custom Aircraft/CRJ700-family/Nasal/master.nas, line 231
  167.06 [ALRT]:nasal        called from: C:/Users/redpa/Documents/FlightGear/Custom Aircraft/CRJ700-family/Nasal/master.nas, line 22
  167.06 [ALRT]:nasal        called from: C:/Users/redpa/Documents/FlightGear/Custom Aircraft/CRJ700-family/Nasal/master.nas, line 30

Unfortunately there's something causing large frame drops which weren't there before in the CRJ700 - it's hard to say what's causing it though.

[tdammers]

My guess would be some of the canvas stuff - the old CRJ uses absolutely no canvas at all, and much of the PFD and MFD functionality is done in XML, whereas canvas tends to be Nasal-driven.

Judging from the E-Jet, keeping the Nasal code for updating a canvas display fast enough is quite a challenge, and Nasal doesn't exactly have advanced debugging and profiling toolchains available, so it's often a matter of trial-and-error (and with a lot of statistical noise).

[jsb]

I appreciate seeing the jsbsim FDM

There is a nasal error, on the off-chance you are not aware of it:

Code: Select all

Nasal runtime error: undefined symbol: update_pass_signs
  167.05 [ALRT]:nasal        at C:/Users/redpa/Documents/FlightGear/Custom Aircraft/CRJ700-family/Nasal/master.nas, line 231
  167.06 [ALRT]:nasal        called from: C:/Users/redpa/Documents/FlightGear/Custom Aircraft/CRJ700-family/Nasal/master.nas, line 22
  167.06 [ALRT]:nasal        called from: C:/Users/redpa/Documents/FlightGear/Custom Aircraft/CRJ700-family/Nasal/master.nas, line 30

Unfortunately there's something causing large frame drops which weren't there before in the CRJ700 - it's hard to say what's causing it though.

Never noticed that one before, thanks for reporting, I will have a look.
Could you quantify the drop in framerate (e.g. old rate vs. new rate)? I spent quite some time and thoughts on minimizing the canvas updates but maybe that does not work in all cases?

[jsb]

Also I noted with "next" / nightly, that the EICAS control panel does not work, presumably due to an issue with emesary or fgcommand. It works for me with 2020.2.1 though

[legoboyvdlp]

The nightly is 2020.2.1; are you compiling on next? If so, yes, the fix to removecommand() appears to be causing a runtime error in emesary (because removecommand() actually works now )

[jsb]

Right, the nightly is 2020.2.1 and works. Compiling next shows the error at runtime. I did not read the changes on removecommand yet...

[Hyphow]

Hello jsb & tdammers,
First of all, thank you for your iteration of the CRJ-700family, this is a beautiful, quite functionnal and lovely to fly airplane. I flew about 10 hours on the yasim - no canvas version from 2019, on FG 2019.1.1 ... No problem whatshowever.
Since I installed the 2020.1.1 version, after some reading here on the forum, I download and installed the latest version of the CRJ on d-jsb repository: https://github.com/d-jsb/CRJ700-family

When I select this version of the CRJ in the launcher the plane loads succesfully but the canvas doesn't seem to work. It opens like that:


I can start the plane, but the PFD, MFD, & EICAS display this message: "No source".
I wonder what is the issue here. Maybe the 2020.1.1 should be incriminated? Is it a stable version? I downloaded it here: http://download.flightgear.org/builds/2020.1/?C=M;O=A

[tdammers]

I'm seeing the same thing actually. It seems that there are some Nasal errors that cause the EFIS code to crash, and after that, the displays don't get updated anymore.

I'll look into it when I can make the time.

[Hooray]

Judging from the E-Jet, keeping the Nasal code for updating a canvas display fast enough is quite a challenge, and Nasal doesn't exactly have advanced debugging and profiling toolchains available, so it's often a matter of trial-and-error (and with a lot of statistical noise).

Speaking in general, you may want to look at Richard's F15 and the corresponding fgdata helpers he's been adding to $FG_ROOT/Nasal
Broadly speaking, you'll probably want to use his MFD framework, too - because it provides a straightforward mechanism (interfacing boundaries) to separate state retrieval/updating of canvas properties and actual rendering.

Other than that, Nasal code is typically executed via listeners and timers - thus -depending on your background- you can easily overload the underlying APIs either in Nasal space, or in C++ space to build a hash/STL map with SGTimeStamps to contain details from the Nasal callstack - the latter of which can be obtained by looking at the implementation of the naRuntimeError() API - basically, you can get the file/module name and line number of the ORIGIN of a listener/timer registration, and then take it from there to also get the function.

That way, it is comparatively straightforward to debug/profile even sophisticated Nasal frameworks - then again, I don't disagree with your underlying point at all, i.e. Nasal's debugging support could indeed be much better, and it's a long standing idea to optionally make such diagnostics/metrics and stats available - for starters via properties, and later on, also using dedicated UI dialogs.

Once that data is provided per module/namespace, it can be easily visualized at run time - and in fact, jsb has done some work related to overloading/tracking listeners/timers, as part of the addon framework.

When it comes to creating MFD avionics via the Canvas system the key takeaway really is stop using getprop/setprop (or props.nas) "as is", and instead use a dedicated MFD framework approach, to encapsulate all getting of state (property, navdb etc) - similarly, polling and timers are often not doing what people expect them to do, same goes for listeners which can easily be invoked too frequently.

Sooner or later, it would make sense to do away with listeners and timers to build up whole subsystems in scripting space, and instead expose the SGSubsystemMgr classes in SimGear to scripting space, so that things like avionics can indeed use a proper C++ interface.


http://wiki.flightgear.org/Howto:Reset/ ... leshooting


http://wiki.flightgear.org/Howto:Troubl ... _Callbacks

[Hyphow]

I'm seeing the same thing actually. It seems that there are some Nasal errors that cause the EFIS code to crash, and after that, the displays don't get updated anymore.

I'll look into it when I can make the time.

Hello tdammers, I did the test again but this time with FG 2020.2.1 nightly version. The glass cockpit works with Canvas, bingo! But I have a new bug, + a new problem: The "B" key seems to be mapped with the ground power button in the left top of the head pannel instead of the parking brake. There is no 3D command for the park brake in the cockpit so I simply can't move on the ground at all!
Otherwise the plane from d-jsb repository flies pretty good. The FDM and masses seems more realistic than the non-canvas version. It is a real pleasure to fly SID and STARS in full manual mode, without any help from the autopilot.

Regards,
Gaetan.

[jsb]

Hi Gaetan,
the "B" is mapped to the parking brake which I abuse as the criterion for "ground service available", that is: parking brake set = ground power avail (unfortunately no lovely 3D model of ground power unit included so far).
Once you release the parking break, some fast and invisible ground worker will remove the also invisible ground power unit out of your way
The 3D lever is missing in the model and I did not consider it important so far... I just type "B"
Thanks for the positive feedback on the FDM - please do not expect the autopilot to work nicely (it works, but needs some love / tuning).
Henning

[jsb]

Regarding performance: I wrote the canvas EFIS framework having in mind to minimize the updates done by nasal code, among others by using listeners, disabling updates for display pages not shown on any screen, reducing update frequency etc...
However, I put quite some hardware into my PC so I might not see performance hits so quickly :/