Flight Management System initialization issue with FlightGear 3.7.0 (Git)

[AvroRJX]

With the latest version of FlightGear from the git repository, after entering a company route into the MCDU the following error appears repeatedly on the console:

setprop() value is not string or number: at /usr/share/games/flightgear-data-9999/Aircraft/A320neo/Nasal/FMGC/fmgc_loop.nas, line 241 called from: /usr/share/games/flightgear-data-9999/Aircraft/A320neo/Nasal/FMGC/fmgc_loop.nas, line 3137 You have encountered a bug in the A320neo model. Please, report it along with the above message and description of what you were doing when it happened to https://github.com/FGMEMBERS/A320neo/issues

After entering all the required data on the INIT page it is normally possible to view the flight plan by pressing the F-PLN button. After this error occurs only the destination airfield is visible on the page hence its not possible to complete the flight plan by entering a SID etc. so the FMS is unusable.

If you need any further information to track down this bug please let me know.

[jan-hudec]

@AvroRJX , did you also try with stable flightgear (and the same revision of A320neo)? Does it work with that?

Also it might only be failing with some routes. Can you please mention the values you entered?

[AvroRJX]

Sorry, I should have said that the aircraft was initialised at Gatwick (EGKK) and I tried routes MIALGWFRA1 and MIALGWFRA2, both show this issue. I've also tried the latest A320neo code with FlightGear 3.4, although on a different platform, and that works fine. This suggests it's due to some recent changes to FlightGear.

After a bit of experimentation I've found a work around. If after entering the company route into the MCDU you immediately open the Route Manager window from the AUTOPILOT menu everything works as before and the full flight plan can be viewed on the MCDU. Hopefully this might provide so insight on how to fix it.

[jan-hudec]

Thank you very much.

I'll build development FlightGear then. It might take me some time to get around to it though.

[jan-hudec]

I have current FlightGear built and I reproduced the issue.

When the flight plan is inserted, the departure and destination airports are inserted without specifying runways. In FlightGear from next that however results in the length of first leg (/autopilot/route-manager/route/wp[1]/leg-distance-nm) in being -NaN and the total distance being -NaN as well and when these are read to Nasal, they come up as nil and cause crash. The route manager dialog fixes it, because in its initialization, departure runway is forcibly selected.

What I am not sure is how to fix it. I could try to work it around by changing the order or by defaulting the runway on the A320neo side, but given that the C++ side behaviour is inconsistent, I suspect it should be fixed in FlightGear instead. The current version returns definite values when the departure and destination are set first and then waypoints added, but undefined (NaN) values when done the other way around as the fmgc code does, because it is easier (it can append the waypoints instead of inserting them before the destination).

[jan-hudec]

I have prepared version that defaults the runways, but as I am testing it, flightgear often crashes when I change the route (usually via the dialog; In FMGC I don't see a way to return to previous waypoint or change destination without clearing the route, the two things I found so far that cause crashes). So I'll probably have to add debugging of flightgear itself.

[FGDATA]

Hopefully it works!!

[jan-hudec]

@FGDATA, well, it works and I don't think it breaks realism much since you need to go through runway selection to select SID/STAR anyway, so I'll push it out.

But as I said, Route Manager seems broken on the current FlightGear next anyway. I'll rebuild FG with full debug and will try to debug it, but that will obviously be different bug in different tracker.

[IAHM-COL]

yes. Indeed. Plus, the Fligthgear issue tracker is located elsewhere too. Good luck getting flightgear fixed thou.

On Thu, Sep 10, 2015 at 11:02 PM, Jan Hudec notifications@github.com wrote:

@FGDATA https://github.com/FGDATA, well, it works and I don't think it breaks realism much since you need to go through runway selection to select SID/STAR anyway, so I'll push it out.

But as I said, Route Manager seems broken on the current FlightGear next anyway. I'll rebuild FG with full debug and will try to debug it, but that will obviously be different bug in different tracker.

— Reply to this email directly or view it on GitHub https://github.com/FGMEMBERS/A320neo/issues/8#issuecomment-139460881.

[FGDATA]

http://sourceforge.net/p/flightgear/codetickets/?source=navbar

I believe there is where a ticket for a bug in flightgear can be submitted .

[jan-hudec]

@FGDATA, am I right that the A330-300 uses the same FMGC and will therefore need the same fixes?

[FGDATA]

I also believe so

[jan-hudec]

@FGDATA, oh, we have both A330-300 and A330-200 as separate repositories. That would be candidate for merging. Maybe one day when I've polished the A320.

In fact, I'd even consider merging all of A320, A330 and A340, because they share the flight management and flight laws, most of the cockpit (A320 and A330 only differ in lack of the fuel jettison button in the former, A330 and A340 only differ in number of thrust levers) and large parts of the models, including the various auxiliary models like power box, stairs, pushback and such (hm, those should really go in the fgdata, because almost every plane needs them). But of course it would be quite a bit of work.