Closed gbiggs closed 9 years ago
This problem is due to a bug in OpenRTM. The default configuration set is supposed to exist at all times, but it does not get created until the first call asking for a list of all configuration sets. rtcryo makes that call several times (rtconf makes it, too), causing the "default" set to get created before rtcryo gets the list of sets to save in the XML file.
From 東京都立産業技術研究センター 佐々木さん
rtresurrect ends up with the following error message and doesn't restore configuration parameters specified in a system profile saved with rtcryo.
rtresurrect: No such configuration set: default
Workaround: A. Execute rtresurrect 3 times with the same system profile. B. Alternatively, make all the RT components composing the system have some `conf.default' properties at initialization even if the configuration parameters are not used
Test environment:
How to reproduce the problem:
Causes: ConsoleIn doesn't have the
conf.default' property at start [02]. But rtcryo has side effects to add the
conf.default' property to the component [08]-[10]. On executing rtcryo after changing config parameters in DoodleDoo, it saves the active config set specification for ConsoleIn in test_sys2.xml [14].Because ConsoleIn doesn't have the `conf.default' property at restart [17], executing rtresurrect with test_sys2.xml will raise NoConfSetError [21].
NoConfSetError exception raised for ConsoleIn keeps DoodleDoo away from configuration restoration since "DoodleDoo" is after "ConsoleIn" in order of actions taken by rtresurrect [22]. see /usr/local/lib/python2.7/dist-packages/rtshell/rtresurrect.py, Line 236.
DoodleDoo.py (test component):