#2812 c172p property rules monostable <time> tag throws error
Loading c172p from next, fgfs.log shows this error:
9.27 [INFO]:autopilot /fgfs/flightgear/src/Autopilot/autopilotgroup.cxx:188: Reading property-rule configuration from Path "/fgfs/fgdata/Aircraft/c172p/Systems/electrical.xml"
9.27 [INFO]:autopilot /fgfs/flightgear/src/Autopilot/autopilotgroup.cxx:200: adding property-rule subsystem unnamed_autopilot_108
9.27 [INFO]:autopilot /fgfs/flightgear/src/Autopilot/component.cxx:55: Component::configure: unknown node: time
9.27 [INFO]:autopilot /fgfs/flightgear/src/Autopilot/autopilotgroup.cxx:188: Reading property-rule configuration from Path "/fgfs/fgdata/Aircraft/c172p/Models/Interior/Panel/Instruments/kap140/kap140-proprules.xml"
9.28 [INFO]:autopilot /fgfs/flightgear/src/Autopilot/autopilotgroup.cxx:200: adding property-rule subsystem unnamed_autopilot_109
9.28 [INFO]:autopilot /fgfs/flightgear/src/Autopilot/component.cxx:55: Component::configure: unknown node: time
These errors are related to 'monostable' flip flop component. Other error follow so I'm not sure if the monostable is stopping other compnents from properly loading:
9.29 [WARN]:general /fgfs/simgear/simgear/structure/subsystem_mgr.cxx:646: adding subsystem to group with name 'display FPM while closing to preselected altitude_0', but subsystemId() returns 'display FPM while closing to preselected altitude'
9.29 [WARN]:autopilot /fgfs/flightgear/src/Autopilot/autopilot.cxx:228: Duplicate autopilot component init, renamed to init_0
9.29 [WARN]:general /fgfs/simgear/simgear/structure/subsystem_mgr.cxx:646: adding subsystem to group with name 'init_0', but subsystemId() returns 'init'
9.29 [WARN]:autopilot /fgfs/flightgear/src/Autopilot/autopilot.cxx:228: Duplicate autopilot component clear GS-arm, renamed to clear GS-arm_0
9.29 [WARN]:general /fgfs/simgear/simgear/structure/subsystem_mgr.cxx:646: adding subsystem to group with name 'clear GS-arm_0', but subsystemId() returns 'clear GS-arm'
9.29 [WARN]:autopilot /fgfs/flightgear/src/Autopilot/autopilot.cxx:228: Duplicate autopilot component check pitch trim run-away, renamed to check pitch trim run-away_0
9.29 [WARN]:general /fgfs/simgear/simgear/structure/subsystem_mgr.cxx:646: adding subsystem to group with name 'check pitch trim run-away_0', but subsystemId() returns 'check pitch trim run-away'
Thanks.
I have run debug with a breakpoint at component.cxx @ 52 :
if( !configure(*child, cname, prop_root)
&& cname != "params" ) // 'params' is usually used to specify parameters
// in PropertList files.
( That's just before the error log gets created ) .. and stepped through kap140-proprules.xml components until cname == 'time' when I set a breakpoint at Autopilot/flipflop.cxx @ 301:
bool MonoFlopImplementation::configure( SGPropertyNode& cfg_node,
const std::string& cfg_name,
SGPropertyNode& prop_root )
{
if( JKFlipFlopImplementation::configure(cfg_node, cfg_name, prop_root) )
return true;
if (cfg_name == "time") {
_time.push_back( new InputValue(prop_root, cfg_node) );
return true;
}
return false;
}
where the 'time' tag ought to get configured; that breakpoint doesn't fire.
Uh, what's the value of "cfg_name" then ?
Uh, it doesn't get to the place where there would be a cfg_name
which "version" of the craft are you trying to use, huntley? how did you acquire it? from the launcher using one of the available hangers or manually by pulling from SVN or GIT? if via SVN or GIT, which branch? if via the launcher, which hanger?
the only other thing i can think of is to remove the c172p.xml file from the aircraft-data directory... it may contain something that is throwing the initialization off... we on the c172p team have seen times where this file needs to be deleted but we have not come up with a good/proper method of ignoring or removing it automatically... i have an idea and will share it with the team at some point soon-ish...
"loading from next"
It's whatever is in fgdata after a fetch and pull from next.
I'm seeing this error integrating Woodstokk's github version of the KAP140 into the Lancair-235 and confirmed the fgfs log shows the same error specifying c172p as the --aircraft
It would be most helpful if you could simply look in the log after having loaded the c172p from a recent 'next' fgdata and look for the record of both
Aircraft/c172p/Systems/electrical.xm
and
/Aircraft/c172p/Models/Interior/Panel/Instruments/kap140/kap140-proprules.xml
to see if the
If you see the same error then I can continue to debug the code path through monstable flip flop. If you don't see the error then I'll start clearing out local data, thanks.
Last edit: Huntley Palmer 2023-06-26
Based on this reading: is the issue with the GitHub updates to the KAP140, maybe?
I don't think so because the error fires also on electrical.xml at the monostable , again used in a property rule.
Edit I did a quick scan , SenecaII uses a monostable in the Century-III AP code, that throws the same error. A320 uses many monostables, I don't know if the error throws but, in the A320 there doesn't seem to be a <name> tag between <flipflop> and type monostable tags. </flipflop></name>
Last edit: Huntley Palmer 2023-06-26
Here's a summary of stepping through the source, omitting excursions into string comparison functions, cfg_name is 'time' at all steps but, inside flippflop.cxx 415 through 455 each type of flipflop: D, J, S etc is check bot not 'monostable, thus returning 'false' to component.cxx and triggering the error log.
( the value of cfg_name is after each step's line number )
flipflop.cxx 152 time
flipflop.cxx 403 time
flipflop.cxx 412 time
digitalcomponent.cxx 65 time
digitalcomponent.cxx 79 time
digitalcomponent.cxx 109 time
component.cxx 71 time
component.cxx 77 time
component.cxx 81 time
component.cxx 87 time
component.cxx 115 time ( return false; )
digitalcomponent.cxx 115 time ( } )
flipflop.cxx 415 time
flipflop.cxx 430 time
flipflop.cxx 435 time
flipflop.cxx 440 time
flipflop.cxx 445 time
flipflop.cxx 450 time
flipflop.cxx 455 time
flipflop.cxx 460 time ( return false; )
component.cxx 52 N/A
component.cxx 53 N/A
component.cxx 55 N/A ( log error )
Agreed that flipflop.cxx FlipFlop::configure does not handle "time" as a config node name, but then I wonder, how long has this been like this? Going to compare with 2020.3...
And 2020.3 seems to have basically identical code. Very strange.
I put together a unit test for monostable based on the digital noise filter test but unfortunately I cannot make the unit tests, failing at some propert aliasing tests, files attached:
Edit test_props compile failure patched and attached files corrected:
Last edit: Huntley Palmer 2023-06-27
The above monostable unit test compiles, runs and fails on the last assert: that after timeout the output should return to stable state and does not.
Thanks Huntely, I'll add this into the test-suite and get it working.
I tried a simpler version of the monostable test, attached, which doesn't have the inverted output and the inverted Set input , reading the wiki description the output should be zero until the Set input is true; this utest fails at the beginning with its outpu active. Please let me know what I'm getting wrong , thanks !
Last edit: Huntley Palmer 2023-06-28
Sorry for the delay, I got around to testing the test now. Using the second version of the monostable test, I fixed the issue of failing on start: this happens becauuse the digital inputs to flip-flops (R, S, J, etc) are not Input-values in the Autopilot ense, but conditions. The sgReadCondition code has no support (for now...) for interpreting a 'naked' string value such as /foo/bar as a property.
I editing the XML definition to specify
as <property>/test/Q and then the whole test worked and passed all the asserts.</property>Is that what you expected?Err, ignore the strike-through in the comment above, SourceForge rich-text markup is strange.
Ah, but I do get the warning about 'time', it's just not visible in the default logs because the test passes.
okay, can fix :)
Fixed in FG commit c54fba1095cdcb8efcfa83dcdac832640c09412a on next