When loading custom DSDL files in the startup dialog the NodeStatus monitor stops working. This is also true for an empty DSDL directory.
My analysis:
After specifying a folder for custom DSDLs the method load_dsdl is called a second time and it replaces the contents of the DATATYPES dict. Because the datatype objects contain closures they are generated anew. The problem arises when a new frame is received and the frames datatype and the NodeStatus datatype are compared. It seems the NodeStatus datatype used in the comparison originates from the first load of the DSDL files and the datatype of the received frame orinates from the DATATYPES dict. Because of the closures this comparison returns False even if both messages have the NodeStatus type.
There are multiple approaches to this problem that I can think of:
Not overwriting the contents of the DATATYPES dict when it already loaded a definition.
Basing the comparison of datatypes on the signature instead of the comparison of the python objects.
Pseudo:
When loading custom DSDL files in the startup dialog the NodeStatus monitor stops working. This is also true for an empty DSDL directory.
My analysis: After specifying a folder for custom DSDLs the method
load_dsdl
is called a second time and it replaces the contents of theDATATYPES
dict. Because the datatype objects contain closures they are generated anew. The problem arises when a new frame is received and the frames datatype and the NodeStatus datatype are compared. It seems the NodeStatus datatype used in the comparison originates from the first load of the DSDL files and the datatype of the received frame orinates from theDATATYPES
dict. Because of the closures this comparison returns False even if both messages have the NodeStatus type. There are multiple approaches to this problem that I can think of:DATATYPES
dict when it already loaded a definition.