# Nav hold not possible with XML gauge

## Recommended Posts

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

##### Share on other sites
 Help AVSIM continue to serve you!Please donate today!

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

##### Share on other sites

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

##### Share on other sites

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

##### Share on other sites

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

##### Share on other sites

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

##### Share on other sites

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"

##### Share on other sites

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

##### Share on other sites

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

##### Share on other sites

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"

##### Share on other sites

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

##### Share on other sites

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

##### Share on other sites

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

##### Share on other sites

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

##### Share on other sites

Hi Rob,Comments and whitespaces don't affect a program's performance no matter the language it is written in (read C++,VB XML,etc) as they are automatically ignored on code loadup; so you may "comment" an entire paperback inside a gauge and fps won't drop a bit!:-) though the gauge loading time will increase as you already stated. My point was refered to limit the use of too much branching and nested conditionals (if..els..&& etc) that DO affect the system's performance, when speaking of programs with tenths of thousands of code lines. I am not sures if this may apply to XML efficiency though.For instance, let's compare these pieces of code:(A) 1 > (:( 5 < && if{ 1>XX } els{ 0>XX }(A) 1 > (:( 5 < && >XXIn the first case we have one jump and two extra bytes in memory. A jump is needed to get the "1" or "0" byte, each of one holds its own memory position. In the second case, we don't need a jump as the resulting byte is stored in the XX memory position, then we don't need the "1" and "0" bytes as well. Hypotetically I mean, multiply this basic example to the entire gaugeset of a panel and you should have to find some kind of increased performance. The point is, is it worth in XML? I really don't know; actually I prefer, like you, to make the code more readable, although trying to use "shortcuts" whenever I can providing I will understand the meaning when I need to come back to it:-)Maybe a programming guru can enlighten us a little bit...( or better, is willing to make the proper testings:-) )Regards,Tom

## Create an account

Register a new account

• Tom Allensworth,
Founder of AVSIM Online

• ### Hot Spots

• Flight Simulation's Premier Resource!

AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!