Nav hold not possible with XML gauge

[Guest Matthias Lieberecht]

Hi All,It seems that I'm having a big problem with a very simple gauge. Here is the code:(A:Plane heading degrees gyro,degrees) (A:Autopilot heading lock dir,degrees) - s5 l5 180 > if{ l5 360 - (>L:BC Calculation, percent) } els{ l5 -180 < if{ l5 360 + (>L:BC Calculation, percent) } els{ l5 (>L:BC Calculation, percent) } } }(L:BC Calculation, percent) -101 > (L:BC Calculation, percent) - 101 < && if{ 0 (>L:BC Possible Mode, bool) } els{ 1 (>L:BC Possible Mode, bool) }(L:AP Main Switch, bool) (A:Autopilot flight director active,bool) || (L:AP APR Switch, bool) (L:AP NAV Switch, bool) 0 == && && if{ (L:BC Possible Mode, bool) if{ (A:Autopilot approach hold, bool) if{ 1 (>K:AP_APR_HOLD) } (A:Autopilot nav1 lock, bool) if{ 1 (>K:AP_NAV1_HOLD) } (A:Autopilot backcourse hold, bool) 0 == if{ 1 (>K:AP_BC_HOLD) } } els{ (A:Autopilot nav1 lock, bool) if{ 1 (>K:AP_NAV1_HOLD) } (A:Autopilot backcourse hold, bool) if{ 1 (>K:AP_BC_HOLD) } (A:Autopilot approach hold, bool) 0 == if{ 1 (>K:AP_APR_HOLD) } } }(L:AP Main Switch, bool) (A:Autopilot flight director active,bool) || (L:AP APR Switch, bool) 0 == (L:AP NAV Switch, bool) && && if{ (L:BC Possible Mode, bool) if{ (A:Autopilot approach hold, bool) if{ 1 (>K:AP_APR_HOLD) } (A:Autopilot nav1 lock, bool) if{ 1 (>K:AP_NAV1_HOLD) } (A:Autopilot backcourse hold, bool) 0 == if{ 1 (>K:AP_BC_HOLD) } } els{ (A:Autopilot backcourse hold, bool) if{ 1 (>K:AP_BC_HOLD) } (A:Autopilot approach hold, bool) if{ 1 (>K:AP_APR_HOLD) } (A:Autopilot nav1 lock, bool) 0 == if{ 1 (>K:AP_NAV1_HOLD) } } }(L:AP APR Switch, bool) 0 == (L:AP NAV Switch, bool) 0 == && if{ (A:Autopilot approach hold, bool) if{ 1 (>K:AP_APR_HOLD) } (A:Autopilot nav1 lock, bool) if{ 1 (>K:AP_NAV1_HOLD) } (A:Autopilot backcourse hold, bool) if{ 1 (>K:AP_BC_HOLD) } }The gauge checks the selected course and should now activate BC, Nav or Apr hold depending on the actual course. The problem is, that I could not activate Nav hold. The autopilot always tries to activate Apr hold (although the switch (L:AP APR Switch, bool) is off and the Nav switch (L:AP NAV Switch, bool) is on. The result is a completely wrong action of the AP. How is it possible to tell the AP that, if I activate the Nav hold switch, I just want to activate Nav or BC hold and NOT APR hold. The tooltip text always shows Apr hold off, on, off, on,... and it seems that there is alays a command for the switch although the switch is off! The tooltip text of Nav hold is always off, no matter which of the two buttons is pressed. Hope someone could find the bug in the above code.Best RegardsMatthias

[taguilo 33]

Hi,I'll check the whole formula later, but at first glance I count 4 open brackets ({) and 5 closed brackets (}) in this element. Don't know how may affect the result...(A:Plane heading degrees gyro,degrees)(A:Autopilot heading lock dir,degrees) - s5 l5 180 > if{l5 360 - (>L:BC Calculation, percent) } els{ l5 -180 L:BC Calculation, percent) } els{ l5(>L:BC Calculation, percent) } } }Tom

[taguilo 33]

...and I guess it should be _ON or _OFF after K:AP_NAV1_HOLD and the rest of the events ? Tom

[Guest Matthias Lieberecht]

Hi Tom,Thank you very much. Yes, you were right and there was one bracket too much in the first code. I thoght this was the solution but unfortunately it wasn't. I've corrected it but the result is the same. The AP always just want to activte Apr hold and fully ignores BC and Nav hold."and I guess it should be _ON or _OFF after K:AP_NAV1_HOLDand the rest of the events ?"The thing I've used is a "toggle" like it is used in the standard 747 AP, so it should work. I've also tried (>K:AP_BC_HOLD_OFF), (>K:AP_NAV1_HOLD_OFF), (>K:AP_APR_HOLD_OFF) and the same with the _On commands but without result. The Apr always switches on and off frequently and Nav and BC didn't switch at all. A simple funtion but I do not know why it won't work.Best RegardsMatthias

[taguilo 33]

Matthias,I would try using a macro like this:(A:Autopilot nav1 lock, bool) (L:AP Nav On) || Then test the macro's state :@APNavOn if{ (>K:AP_NAV1_HOLD_OFF) 0 (>L:AP Nav On) }els{ (>K:AP_NAV1_HOLD_ON) 1 (>L:AP Nav On) }And avoid to use the "toggling" method as possible. It's been discussed here that gauge events refreshing occurs on the next cycle, so it may happen that (A:Autopilot approach hold, bool), for instance, is still active after the XXX_NAV1 event is called.best regards,Tom

[Guest Matthias Lieberecht]

Hi Tom,Thank you very much. I highly appreciate your trying to help me. Unfortunately I have no luck. I've deleted everything (just for trying) which has somethig to do with approach hold. There's no longer an APR hold switch in and in no gauge has any APR function (searched with the Explorer for any left-overs). The last thing I did was to add the following line in the AP:(L:AP Main Switch, bool) (A:Autopilot flight director active,bool) || (L:AP NAV Switch, bool) (L:BC Possible Mode, bool) 0 == (A:Autopilot nav1 lock, bool) 0 == && && && if{ 1 (>K:AP_NAV1_HOLD_ON) 1 (>K:AP_BC_HOLD_OFF) }If you believe it or not. The AP switches on APR hold and ignores NAV hold. I have additionally included the 737 AP to see what happens. The same thing. If I press my Nav button the APR goes on and Nav stays off. The only thing which has changed with the above code was that the frequently switching on and off has stopped. BTW: I have also tried the above code without "1" before the _off and _on functions (just to see what happens - but no difference. A real phenomenon. I suppose that it has something to do with the AP_NAV1_HOLD_ON function but I'm absolutely perplexed because it's not the first AP I'm making.Best RegardsMatthias

[phjvh 0]

Hi,"My test"Parameters are lights reacting on:(A:AUTOPILOT BACKCOURSE HOLD, bool)(A:AUTOPILOT NAV1 LOCK,bool) and(A:AUTOPILOT APPROACH HOLD,bool)Pressing:(>K:AP_BC_HOLD) then BC and APPR light ON.(>K:AP_BC_HOLD) again then BC OFF and APPR stays ON.(>K:AP_APR_HOLD) then APPR (and BC) OFF.(>K:AP_NAV1_HOLD) then NAV1 light ON.(>K:AP_NAV1_HOLD) again then NAV1 light OFF.When BC and or APPR lights ON, these lights go OFF when pressing (>K:AP_NAV1_HOLD) first time.(>K:AP_APR_HOLD) then APPR light ON.(>K:AP_APR_HOLD) again then APPR light OFF.When NAV1 light is ON, it goes OFF when pressing (>K:AP_APR_HOLD).As already stated, when BC light is ON it goes OFF when pressing (>K:AP_APR_HOLD).So it seems that when pressing BC, APPR is also activated.Never noticed that because i don't use BC.Maybe this co-action has influence on the gauge.Jan"Beatus Ille Procul Negotiis"

[Guest Matthias Lieberecht]

Hi Jan,Thank you very much for this very helpful information. Because of this I gave my first version a second try together with the installed 737 AP. When I switch on Nav hold, APR and BC goes on on the 737 AP. So the bug is not in the code for activating NAV, BC and APR but in the code which I've used to calculate which mode has to be activated. I've made a couple of tryings in the meantime and it seems that my calculation always gives back "BC on". But now that I know where I have to look for the bug, I'm sure I'll find it.Best RegardsMatthias

[Guest Matthias Lieberecht]

Hi All,I HAVE IT :-)The correct codeline is:(A:Plane heading degrees gyro,degrees) (A:NAV1 OBS, degrees) - s5 l5 180 > if{ l5 360 - (>L:BC Calculation, percent) } els{ l5 -180 < if{ l5 360 + (>L:BC Calculation, percent) } els{ l5 (>L:BC Calculation, percent) } }(L:BC Calculation, percent) -101 > (L:BC Calculation, percent) 101 < && if{ 0 (>L:BC Possible Mode, bool) } els{ 1 (>L:BC Possible Mode, bool) }There were 3 (in words three) bugs in my older calculation code. Now, with the correct code and calculation it works perfect. If the selected course is more than 100 degrees from the current flying course BC will be activated no matter if APR or NAV is pressed. If the selected course is less than 100 degrees APR will be activated when APR is pressed and NAV will be activated when Nav is pressed. Once again, thank you very much Tom and Jan for your help. Without it I'm sure I wouldn't find the fault.Best RegardsMatthias

[phjvh 0]

OK Matthias!But a question:Can you give the whole corrected code again and for what kind of autopilot you use it? Automatic switching of BC or a capture when BC is pressed? or are all 3 switches pressed?Jan"Beatus Ille Procul Negotiis"

[taguilo 33]

Matthias,Great you found the way. It seems the key was to replace (A:Autopilot heading lock dir,degrees) with (A:NAV1 OBS, degrees) ? (at least in the code you posted).By the way, this is a short variant of the second element:(L:BC Calculation, percent) -101 > (L:BCCalculation, percent) 101 < * (>L:BC Possible Mode, bool) }Less clear but, could it be more speed/memory efficient? Imagine the level of performance gain if we could make it portable to the whole code of a panel. Maybe someone could test whether a real improvement results when replacing all those if..els..&& with math operators to reduce code lenght.GreetsTom

[rcbarend 37]

Hi Tom,Here's my opinion on XML code optimisation.As far as I know, XML "code" is interpreted on load of the gauge.I very much doubt that whatever optimisation you do in your XML code will have any measurable impact on the framerate. What WILL have impact on fps, is quantity and size of the used bitmaps.I've made (and maintained) quite some XML gauges over the years, but personally I find maintainabililty of the code (if not for others, then at least for myself :-) ) much more important than size of the XML file. Hence I use a lot of comment, whitespace etc in my code, and avoid the use of d, s*, and r* operators as much as possible since it makes the code very unreadable IMO.And as said: from what I've experimented in the past, I've not been able to see measurable difference after "optimising code for execution".A nice experiment:I did a test once with an all-XML (2D) panel of 200+ gauges, and compared fps when running gauges at the default 55 msec schedule, and at 500 sec schedule. And as you might guess: no measurable difference in fsps.Hence my opinion that code optimisation for the sake of performance (NOT: clarity !) is not worthwhile.Of course I might be wrong, in that case I stand corrected :-) ..What WILL have impact on performance (i.e. on load time of the panel), is whether the XML code is packed in a .cab file, or "uncabbed" into a subfolder with the same name.I recently tested a (shortly to be released) very complex all-XML panel (about 900 files , xml and .bmps) in the .cab file. With the gauges in the .cab file, the loadtime (on my PC) of the aircraft was about 50 sec; with the files unpacked, the loadtime was about 20 sec. (many repeated tests !)Cheers, Rob Barendregt

[Guest Matthias Lieberecht]

Hi All,@Jan,At the moment I'm not at home. As soon as I'm back at my own computer, I will post the complete code for the BC function here. It is for an Avro RJ Autopilot/DFGC System. The MCP of the autopilot contents two buttons, VOR/LOC and APP. The AP always scans the difference of the OBS course and the actual course. If the OBS course is within 100 degrees it engages Nav hold (if VOR/LOC is pressed) and APR hold (if APP is pressed). If the OBS course is larger than 100 degrees it engages BC hold if VOR/LOC or APP is pressed. There is no separate BC Button on the MCP. I think (but I'm not sure) the modern Airbus autopilots (A318 - A340) have the same function, because there is also no BC button available and I know that BC hold is possible with those types.@Tom,Yes, using (A:Autopilot heading lock dir,degrees) instead of (A:NAV1 OBS, degrees) was the reason why I never see any difference when selecting another course. The second main bug was a too much "-" before the second 101 in the line:(L:BC Calculation, percent) -101 > (L:BCCalculation, percent) - 101 < && if{ 0 (>L:BCPossible Mode, bool) } els{ 1 (>L:BC Possible Mode, bool)}This was the reason why I always get back "BC on" (L:BC Possible Mode, bool).I would also prefer a faster method to calculate this thing. Maybe someone could shorten it. However it don't need such a lot of computing that you could recognize it with the framerates.Best RegardsMatthias

[Guest Matthias Lieberecht]

Hi Rob,"I recently tested a (shortly to be released) very complex all-XML panel (about 900 files , xml and .bmps) in the .cab file. With the gauges in the .cab file, the loadtime (on my PC) of the aircraft was about 50 sec; with the files unpacked, the loadtime was about 20 sec. (many repeated tests !)"Thank you very much for the info. That's absolutely interesting. Especially my newer BAe 146 panel and the ARJ panel on which I'm currently working, need a very long time until the aircraft is loaded into the flightsimulator. I could go drinking a coffee until everything is loaded (with a bit burlesque :-) ). Nevertheless it has good frames once loaded. If this fasten the loading time it's a great step forward. Maybe it also fasten the framerates a bit. I will try it when the complete panel is ready to use.Best RegardsMatthias

[rcbarend 37]

Hi Matthias,Yes, uncabbing the gauges will help a lot.But it won't effect framerate after it's loaded (all the gauges have been interpreted then, and now run in memory).Best regards, Rob