#2859 turn_indicator.cxx name change causes failure

[Huntley Palmer]

flightgear/src/Instrumentation/turn_indicator.cxx commit aa2e31b35d39afa1f3107bfc69c58afa8a88e833
sets the name of the instrument's power supply to
/systems/electrical/outputs/turn-coordinator"
wheras in 2020.3 the default name would be
/systems/electrical/outputs/turn-indicator"
This name change eddectively makes instruments incompatible between 2020-3 and 2020-4
For example, reiszner's KAP140 proprules detect absence of power at startup in 2020-3 builds but the same KAP140 setup works OK in 2020.4

[James Turner]

Bit confused: that fix was done to put it back to the old compatible name, it sounds as if we have aircraft in the wild which rely on both names maybe?

[Benedikt Hallinger]

I think I paid attention to this and didn't change any names.

And indeed, looking at the log, it says Benedikt WOLF was the commiter. thats nt me :)

$ git show aa2e31b35d39afa1f3107bfc69c58afa8a88e833
commit aa2e31b35d39afa1f3107bfc69c58afa8a88e833
Author: Benedikt Wolf theecho@t-online.de
Date: Mon Apr 24 08:00:54 2023 +0200

Turn Indicator:
* revert to old default power supply path (/systems/electrical/outputs/turn-coordinator > instead of .../turn-indicator) for compatibility reasons
* fix property instrumentation/turn-indicator/spin not being updated

[Benedikt Hallinger]

As a further Info:
The KAP140 detects turn-coordinator failure in an agnostic way, by inspecting the serviceableand operable boolean flags:

<logic>
        <input>
            <and>
                <property>instrumentation/turn-indicator/operable</property>
                <property>instrumentation/turn-indicator/serviceable</property>
            </and>
        </input>
        <output>autopilot/kap140/sensors/turn-indicator-operable</output>
    </logic>

My guess is that affected aircraft are not setting the power-supply config prop of the turn coordinator, thus not getting power to the instrument when just setting "the other" power source prop.

[James Turner]

Ooops sorry, Benedikt confusion :)

[Huntley Palmer]

I'll have to dig further but it's clear the KAP140 works OK using 2020.4 and fails to startup if solely the build is changed to 2020-3 using exactly the same model,
e.g

It's possible a change to AbstractInstrument between 2020-3 and 2020.4 is related:
40
if (_powerSupplyPath.empty()) {
_powerSupplyPath = "/systems/electrical/outputs/" + defaultName + "[" + std::to_string(_index) + "]";
}

[Benedikt Hallinger]

I'll have to dig further but it's clear the KAP140 works OK using 2020.4 and fails to startup if solely the build is changed to 2020-3 using exactly the same model,

I think it has nothing directly to do with the KAP140. The real cause causing this is:
- The aircraft in question does not define an explicit power-source config property, thus the instruments default is initialized (which changed).
- The aircraft in question sets a hardcoded power property, which happens to be /systems/electrical/outputs/turn-indicator. that is not working anymore in next.

Just describing whats going on. No opinion on what the proper fix is; but I think it is always a good idea to explicitely define such config stuff aircraft sided (set a dedicated power-source and write to that, so its stable).
The one side is, that its a good thing to expect properties in the named subnode how its called in the Instrumentation.xml; and the other side of the same medal is, that there exists two different instruments in real life wich are usually modelled by the same c++ instrument: "turn-coordinator" (most motor aircraft) and "turn indicator" (mostly gliders). That may have brought in the confusion initially.
So maybe, in the light of this, Benedikts commit may be better reverted.

[Huntley Palmer]

OK, many thanks for that summary. I think it's true that, for the turn indicator in this model, an explicit power source is not configured; as it's written the model's KAP140 starts up for next, 2020.4 but not in 2020-3.
Will setting an explicit path for the power source allow the one model to work for both builds ?
Thanks !

[Benedikt Hallinger]

Will setting an explicit path for the power source allow the one model to work for both builds ?

I think yes. If the turn coordinator gets power, its operable prop will turn true, making the KAP able to boot.

[Huntley Palmer]

Sorry, I'm still going around in circles, I have set in instrumentation.xml :
~~~
<turn-indicator>
<name>turn-indicator</name>
<number>0</number>
<power-supply>/systems/electrical/outputs/turn-coordinator</power-supply>
<minimum-supply-volts>24</minimum-supply-volts>
</turn-indicator>
~~~turn-indicator

And I can see, in the properties tree
systems/electrical/outputs/turn-coordinator is 24.6xx volts

But KAP140/sensors/turn-indicator-operable shows false so KAP140 doesn't start. I've no idea if, in the above instrument declaration, either the property node of the <name> fiels needs to be changed to turn-coordinator although I suspect AbstractInstrument is looking at a different node for the power source. </name>

[Benedikt Hallinger]

Is the instruments operable property true?

[Huntley Palmer]

/instrumentation/turn-indicator/operable is unset, i.e a blank field in the properties browser ( firefox) the 'serviceable' field is set to bool true.

[Huntley Palmer]

Switching to 'next' : instrumentation/turn-indicator/operable is set and shoes bool true

[Huntley Palmer]

I made up a unit test, files below should be placed in flightgear/test_suite/unit_test/Instrumentation
On 'next' the unit tests run OK, unfortunately for 2020-3 make test_suite fails with this output:

  /blds/fg/2020-3/tsts<=>make test_suite
[ 11%] Built target CppUnitLib
-- Found Git: /bin/git (found version "2.43.0") 
-- Git revision is b5e65d43be4beeaf9e15b95d1a05b29f51206104
[ 11%] Built target buildId
[ 13%] Built target fgsqlite3
[ 33%] Built target iaxclient_lib
[ 47%] Built target flite_hts
[ 50%] Built target hts_engine
[ 50%] Built target hidapi
[ 52%] Built target PLIBFont
[ 52%] Built target PLIBJoystick
[ 52%] Built target fgrcc
fgrcc: writing C++ file: '/blds/fg/2020-3/tsts/src/EmbeddedResources/FlightGear-resources.cxx'
fgrcc: static memory used by resources (total): 0 bytes
fgrcc: writing header file: '/blds/fg/2020-3/tsts/src/EmbeddedResources/FlightGear-resources.hxx'
[ 52%] Built target embeddedresources
[ 52%] Built target fgfs_zh_CN_qm
[ 52%] Built target fgfs_ca_qm
[ 52%] Built target fgfs_de_qm
[ 52%] Built target fgfs_en_US_qm
[ 52%] Built target fgfs_es_qm
[ 52%] Built target fgfs_fr_qm
[ 52%] Built target fgfs_it_qm
[ 55%] Built target fgfs_nl_qm
[ 55%] Built target fgfs_pl_qm
[ 55%] Built target fgfs_pt_qm
[ 55%] Built target fgfs_ru_qm
[ 55%] Built target fgfs_sk_qm
[ 55%] Built target fgfs_tr_qm
[ 55%] Built target fgfs_qm_files
[ 55%] Automatic MOC for target fglauncher
[ 55%] Built target fglauncher_autogen
[ 66%] Built target fglauncher
[ 66%] Automatic MOC for target fgqmlui
[ 66%] Built target fgqmlui_autogen
[ 75%] Built target fgqmlui
[100%] Built target JSBSim
[100%] Automatic MOC for target fgfs_test_suite
[100%] Built target fgfs_test_suite_autogen
[100%] Linking CXX executable fgfs_test_suite
/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/13/../../../../lib64/crt1.o: in function `_start':
(.text+0x1b): undefined reference to `main'
collect2: error: ld returned 1 exit status
make[3]: *** [test_suite/CMakeFiles/fgfs_test_suite.dir/build.make:150: test_suite/fgfs_test_suite] Error 1
make[2]: *** [CMakeFiles/Makefile2:4083: test_suite/CMakeFiles/fgfs_test_suite.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:4116: test_suite/CMakeFiles/test_suite.dir/rule] Error 2
make: *** [Makefile:1382: test_suite] Error 2

[Huntley Palmer]

I've run these models under both 'next' and '2020-3' : pa32, c150, pup150, pc6-b2h4
Under 2020-3 for all those models Instrumentation/turn-indicator/operable node is not created.
Under 'next', for all those models the node is created, only pa32 sets the node operable to true, for the rest the node is false.
I conclude the node isn't created for 2020-3, making the new KAP140 inoperative; for 2020-4 the node is created but likely needs a certain power setup for operable to indicate the KAP140 is usable.

[Huntley Palmer]

The build error for 2020.3 unit tests was due to some tests being missing in 2020.3. Corrected CmakeLists.txt and TestSuite.cxx attached:

[Benedikt Hallinger]

I think the reason is that AbstractInstrument in the instruments inheritance chain (see turn_indicator.hxx). In next, it is.

So probably this is easily solved by backporting the affected commit from next?

[Huntley Palmer]

Sadly it it doesn't solve the issue, as far as I can see:

In 2020-3 flightgear/src/Instrumentation/turn_indicator.hxx
I replaced

#include <simgear/props/props.hxx>
#include <simgear/structure/subsystem_mgr.hxx>

with

#include <Instrumentation/AbstractInstrument.hxx>

and rebuilt 2020-3
Still, the Lancair with resizner's KAP140 still fails after PFT 3,
properties instrumentation/turn-indicator/operable is not set to anything, resulting in KAP140 failure. It seems, to me, an obvious fix is to have the KAP140 not test for operable since it is already testing for serviceable.

[Benedikt Hallinger]

I think you should actually find the commit changing this and apply it.
Or if you include the header file, you need to actually tel the compiler to inherit from it.

[Huntley Palmer]

You lost me at 'tell the compiler to inherit from it'
I've put a copy of flightgear, with the ubit test for turn-instrument/operable
here

[Benedikt Hallinger]

I made a small patch "backporting" just the operable property (against the 2020.3 release branch).
GIT: https://beni.hallinger.org/fgfs.nobackup/flightgear.git/ branch backport_turn_coordinator.

@jmturner @lightwork Tested OK, and KAP140 is working again.

---

diff --git a/src/Instrumentation/turn_indicator.cxx b/src/Instrumentation/turn_indicator.cxx
index 2071820cd..85b2828da 100644
--- a/src/Instrumentation/turn_indicator.cxx
+++ b/src/Instrumentation/turn_indicator.cxx
@@ -48,6 +48,8 @@ TurnIndicator::init ()
         fgGetNode("/systems/electrical/outputs/turn-coordinator", _electrical, true);
     _rate_out_node = node->getChild("indicated-turn-rate", 0, true);

+    _operable_node = node->getChild("operable", 0, true);
+
     reinit();
 }

@@ -111,6 +113,9 @@ TurnIndicator::update (double dt)

                                 // Publish the indicated rate
     _rate_out_node->setDoubleValue(rate);
+
+    // set operable node
+    _operable_node->setBoolValue(power && _gyro.is_serviceable());
 }


diff --git a/src/Instrumentation/turn_indicator.hxx b/src/Instrumentation/turn_indicator.hxx
index f5cfbd9af..b5e6c11de 100644
--- a/src/Instrumentation/turn_indicator.hxx
+++ b/src/Instrumentation/turn_indicator.hxx
@@ -62,6 +62,8 @@ private:
     SGPropertyNode_ptr _yaw_rate_node;
     SGPropertyNode_ptr _electric_current_node;
     SGPropertyNode_ptr _rate_out_node;
+
+    SGPropertyNode_ptr _operable_node;
 };

 #endif // __INSTRUMENTS_TURN_INDICATOR_HXX

[James Turner]

Yep seems reasonable to me.

[Huntley Palmer]

Thank You for the patch, both Lancair-235 and NavionB with the new KAP140 start properly; the unit test for turn indicator new passes OK. Thanks again !