mercedes-benz/odxtools

pdx file list error

minkeetan opened this issue · 6 comments

I encounter error when I try to list pdx file.

It complained that it don't know the type NRC-CONST

Logging:
File "C:\Users\tnm1pg1\AppData\Local\Programs\Python\Python39\lib\site-packages\odxtools\parameters\readparameter.py", line 199, in read_parameter_from_odx
raise NotImplementedError(f"I don't know the type {parameter_type}")
NotImplementedError: I don't know the type NRC-CONST

Do I miss anything?
The command that I use is "odxtools list -a xxx.odx"

KLBa commented

Thanks for raising the issue! You didn't miss anything.
Like the error indicates, reading parameters of type NRC-CONST is not implemented. It throws an error (as opposed to just logging a warning) because I thought all parameter types were already covered... We never noticed because our internal .pdx files don't use NRC-CONST.

I can fix it and implement reading NRC-CONSTs in the upcoming two or three weeks (unless someone else jumps at it faster).

I see. Thanks KLBa. Looking forward to the fix.

KLBa commented

I added a PR #37 for this. @minkeetan could you check if it fixes your issue?

oops, I fat fingered this PR a bit. If it turns out that @minkeetan's problem still persists, let's make a follow-up...

@KLBa , @andlaus

Thanks for this. I have verified the PR and it works. 👍🏽

However, I did see another issue after passing NRC-CONST. It claims that NoneType object has no attribute 'text'
I think I need to bother you again. Shall I open a new issue?

File "C:\Users\tnm1pg1\AppData\Local\Programs\Python\Python39\lib\site-packages\odxtools-1.2.0-py3.9.egg\odxtools\diagdatadictionaryspec.py", line 101, in
structures = [read_structure_from_odx(structure_element)
File "C:\Users\tnm1pg1\AppData\Local\Programs\Python\Python39\lib\site-packages\odxtools-1.2.0-py3.9.egg\odxtools\structures.py", line 394, in read_structure_from_odx
long_name = et_element.find("LONG-NAME").text
AttributeError: 'NoneType' object has no attribute 'text'

hm, okay. This is probably another case of the idiosyncrasies of our internal files baked into the code. (They always seem to have a LONG-NAME here.) PR is on the way, thanks for the catch...