xdd: Implement option to load object dictionary from XDD file.

[zaporozhets]

Hi All,

This is a WIP merge request that adds support for XDD import to CANopen. I'm still in the process of testing and making improvements, but I’d appreciate any feedback you might have in the meantime.

Feel free to share any questions or suggestions.

Best regards,
Taras

[codecov]

Codecov Report

❌ Patch coverage is 70.28302% with 63 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
canopen/objectdictionary/xdd.py	68.61%	44 Missing and 15 partials ⚠️
canopen/utils.py	76.47%	2 Missing and 2 partials ⚠️

📢 Thoughts on this report? Let us know!

[zaporozhets]

Hi @acolomb, could you please take a look?

[acolomb]

Thank you very much for this contribution. Happy to see some progress on the XDD front. I started taking a look and overall I think it's going in a good direction.

Need to take some more time to put down my thoughts in detail, but some high-level pointers first:

• For new code, we expect to have full type annotations. The mypy linter run in the PR checks can give you hints about what needs improvement, or best run it locally. Note that any functions without argument or return type annotations are not even checked by default.
• I don't like the idea of inflating the canopen.utils module, even though avoiding code duplication is a worthy goal. I'll try to come up with a simplification soon.
• Where I do want less duplication is the object code constants declared in both eds.py and xdd.py. Have a look at commits 7c6dee5 and db9110e in master, those can be cherry-picked easily.
• A little more attention to code formatting would be nice. I use flake8 locally and try to keep it from complaining. Will report any outstanding issues during more thorough review.
• I assume there is no copyright involved for the sample.xdd file? I don't know where the CANopenNode project got its references from, but just trying to be careful about legal issues with files we include here.

[acolomb]

Just a partial review again, but I hope you get the general idea... More to come when I get another look with a fresher brain.

[acolomb]

This is a leftover from eds?

[acolomb]

Suggested change

[acolomb]

Suggested change

from typing import TYPE_CHECKING

[acolomb]

Suggested change

	if TYPE_CHECKING:
	import canopen.network

[acolomb]

With static type hints, something like this:

Suggested change

	def import_xdd(xdd, node_id):
	def import_xdd(
	xdd: Union[etree.Element, str, bytes, os.PathLike],
	node_id: Optional[int],
	) -> ObjectDictionary:

[acolomb]

No logging of this failure?

[acolomb]

Suggested change

	return od
	return od

[acolomb]

Suggested change

	def _add_device_information_to_od(od, root):
	def _add_device_information(od: ObjectDictionary, root: etree.Element):

Keep the names slightly shorter, it's all already in the context of the OD.

[acolomb]

Suggested change

	("vendorName", "vendor_name", lambda val: str(val)),
	("vendorName", "vendor_name", str),

This can be simplified in many places, no need for a lambda.

[acolomb]

You could create a autoint = functools.partial(int, base=0) constructor once in this module, then use it to simplify in these cases.

[tomasbarton-stemcell]

hi @zaporozhets, thanks for the work on this PR! Are you still planning to continue with it? I have a project where I could really use xdd/xdc parsing right now, so I'd be glad to pick up where you left off and contribute to this effort if you don't have the bandwidth.

[zaporozhets]

@acolomb, thank you for the review, and @tomasbarton-stemcell for your interest in this feature.

I was extremely busy last year and didn’t have the chance to address all the comments.

I’m currently on sick leave until Monday, so I finally have some time to catch up. Please give me a few days to refresh my memory and go through all the suggestions. I’ll keep you posted. I’ll definitely appreciate a thorough review here, as Python isn’t really my main area of expertise.

BR,
Taras