Hi Thomas,

I didn't make run_to_xml.py work correctly here. But about the error, you can get rid of it by change the line 4 of xml_to_json.py script like this:

- from .structures import Signal, Message
+ from openxc.generator.structures import Signal, Message

I haven't any errors running it then but no signals.json neither. Tell us your results if you could get it works correctly.

Regards.

Romain

Hello,
at the moment I'm working on importing / using my can messages with AGL.
OpenXC xml_to_json.py seems to work if I'm not using "-m openxc.utils" in "python3 -m openxc.utils xml_to_json.py Powertrain.xml mapping.json signals.json"  I get the error "from .structures import Signal, Message"
In the file location there are the files "mapping.json" and  "Powertrain.xml"
I didn't get the signals.json or some output but the script is running.

Some listing of the files are in the pastbin https://pastebin.com/ZS2sBRuW

is the generic name the name I want later to use or is it the name of the signal?

Thank you
Thomas

-- 
Romain Forlot - Embedded Engineer - IoT.bzh
romain.forlot@... - www.iot.bzh - +33675142438 

Hello Romain,

thank you for your reply.
I didn't get the converter working.
I use normally a other software to convert from .dbc to .json.
The format is similar to the openxc-format and with a small script it should be working.

If you want I could show it to you.
First I want to try to convert the can messages with my format and the "script".

I tried to follow the description https://git.automotivelinux.org/src/low-level-can-generator/about/ but  I got following error
"/can-config-generator -m ../../tests/signals.json ERROR: Unhandled exception - type must be string, but is number"

Got some else the OpenXC xml_to_json.py working? And how are other doing the part of can messages?

Greetings
Thomas

Hi,

Back on track ! I would be very interested to see your script yep. Even better if you could may be share it with the community and we will include it as part of the low-can project shipped with the generator. I didn't concentrate so much time on this part :/

About your signals.json conversion to cpp file, I'll need the json file to track the problem down. Documentation needs a refresh following latest changes on this topic... You might need to apply a version value.

Try adding

after the name of your signals collection to see if it helps.

Regards.

Thomas,

Romain is on vacation, he will check your script as soon as he returns.

Fulup

On 26/01/2020 19:16, walzert wrote:

Hello Romain,

thank you for your reply.
I didn't get the converter working.
I use normally a other software to convert from .dbc to .json.
The format is similar to the openxc-format and with a small script it should be working.

If you want I could show it to you.
First I want to try to convert the can messages with my format and the "script".

I tried to follow the description https://git.automotivelinux.org/src/low-level-can-generator/about/ but  I got following error
"/can-config-generator -m ../../tests/signals.json ERROR: Unhandled exception - type must be string, but is number"

Got some else the OpenXC xml_to_json.py working? And how are other doing the part of can messages?

Greetings
Thomas

-- 
Romain Forlot - Embedded Engineer - IoT.bzh
romain.forlot@... - www.iot.bzh - +33675142438 

Hi,

Nice job, thanks. Hoping that information I gave you helped :)

I was a bit absent those last days, I'll follow your project and participate if I could.

I quickly tested it and it seems to lack support of some DBC syntax. I did not succeed to convert DBC example files from opendbc project. But this is a great news !

Regards.

Romain

Hello together,
I made a feasability study to that topic, it is a script and no working software.
https://github.com/walzert/dbc2json
if you are using that you should have a dbc file to test it
some example files are in https://github.com/eerimoq/cantools/tree/master/tests/files/dbc
I have not tested all the different examples, that would be a further step. https://github.com/eerimoq/cantools/blob/master/tests/files/dbc/motohawk.dbc should work.

Have a nice weekend
Thomas

-- 
Romain Forlot - Embedded Engineer - IoT.bzh
romain.forlot@... - www.iot.bzh - +33675142438 

Ok, I'll try that. I should be able to provide you an update for Monday :)

Thanks.

Hello Romain,
thank you for your words and the testing.
I made a short test with:
opendbc-b9a00d36f23453670d604afd333df33c3325692b/toyota_prius_2017_can1.dbc 
opendbc-b9a00d36f23453670d604afd333df33c3325692b/toyota_prius_2017_can0.dbc 

Could you do the same on your computer and test if the messages are usable for agl-low-can-generator?

---
python3 dbc2json_converter.py -i ~/Downloads/opendbc-b9a00d36f23453670d604afd333df33c3325692b/toyota_prius_2017_can1.dbc 
Number of messages 19
Finished

python3 dbc2json_converter.py -i ~/Downloads/opendbc-b9a00d36f23453670d604afd333df33c3325692b/toyota_prius_2017_can0.dbc 
Number of messages 16
Finished
---

What I forgot at the moment is setting the right bus maybe you could do that by hand or change it in my script as default value in line 108.
I have an concept in my mind that will have different can-files for the different bus, I would add a parameter for the bus e.g. "hs" or "ls" in the script as an arg.

It would be nice if it will working for you and you can generate the right .cpp

Thank you
Thomas

-- 
Romain Forlot - Embedded Engineer - IoT.bzh
romain.forlot@... - www.iot.bzh - +33675142438 

Hi,

after some tests, I found some problems but the base are fine to me :)

Ideed, using the commit you provide I managed to generate the JSON file to be used by the generator but I don't understand some of the objects you generate.

By example, the header seems to always be the same:

This parts seems to come from the OpenXC project examples. Which is fine but doesn't fit when you need to generate from a dbc file which does not provide such information.

Then if you want to use them, you should pass them using parameters. Your proposal seems good to me, if we can associate a dbc file with a CAN bus provided by a parameter would be sufficient.

Such mapping would be fine and may be why not be able to append signals to an existing generated file. Example:

python3 dbc2json_converter.py -i ~/Downloads/opendbc/toyota_prius_2017_can1.dbc:hs -i ~/Downloads/opendbc/toyota_prius_2017_can0.dbc:ls

Here that map can1 with hs bus and can0 with ls. Simple.

So, the header of generated JSON shouldn't be static and use of some kind of mapping between dbc file with CAN buses names.

Howevern using the master branch of opendbc project, I still got the following error:

Traceback (most recent call last):
  File "dbc2json_converter.py", line 178, in <module>
    main(sys.argv[1:])
  File "dbc2json_converter.py", line 74, in main
    db = cantools.database.load_file(inputfile)
  File "/home/claneys/.local/lib/python3.7/site-packages/cantools/database/__init__.py", line 180, in load_file
    strict)
  File "/home/claneys/.local/lib/python3.7/site-packages/cantools/database/__init__.py", line 255, in load
    strict)
  File "/home/claneys/.local/lib/python3.7/site-packages/cantools/database/__init__.py", line 344, in load_string
    raise UnsupportedDatabaseFormatError(e_arxml, e_dbc, e_kcd, e_sym, e_cdd)
cantools.database.UnsupportedDatabaseFormatError: DBC: "Invalid syntax at line 4, column 1: ">>!<<CM_ "Imported file _comma.dbc starts here"""

I suspect a problem parsing the newline as my debug stop in the dbc Parser.py matching '\n' character.

Regards.

Romain.

Hello Romain,
thank you for your words and the testing.
I made a short test with:
opendbc-b9a00d36f23453670d604afd333df33c3325692b/toyota_prius_2017_can1.dbc 
opendbc-b9a00d36f23453670d604afd333df33c3325692b/toyota_prius_2017_can0.dbc 

Could you do the same on your computer and test if the messages are usable for agl-low-can-generator?

---
python3 dbc2json_converter.py -i ~/Downloads/opendbc-b9a00d36f23453670d604afd333df33c3325692b/toyota_prius_2017_can1.dbc 
Number of messages 19
Finished

python3 dbc2json_converter.py -i ~/Downloads/opendbc-b9a00d36f23453670d604afd333df33c3325692b/toyota_prius_2017_can0.dbc 
Number of messages 16
Finished
---

What I forgot at the moment is setting the right bus maybe you could do that by hand or change it in my script as default value in line 108.
I have an concept in my mind that will have different can-files for the different bus, I would add a parameter for the bus e.g. "hs" or "ls" in the script as an arg.

It would be nice if it will working for you and you can generate the right .cpp

Thank you
Thomas

-- 
Romain Forlot - Embedded Engineer - IoT.bzh
romain.forlot@... - www.iot.bzh - +33675142438 

Ok, seems fine to me :) What is the meaningof ":w" in your example ? Is it a flag to set it as a writable bus ?

If yes, would it be better to let that in the header.json file which would include your CAN buses settings.

Good work.

Hello Romain,

thank you for your testing and feedback. I'm happy that it worked in a basic way, it was a first proposal and I was not sure if the idea is working properly.
I made some changes based on your ideas, I don't have added all your changes for now, the multi-dbc is a part that is important, but I have to see how to do that in a good way.
I made a external header.json  and the example_header.json  (as a copy) file which could be edited easily, and I added a parameter for  the bus with -b, I not included more can-files.
I put the information for the canbuses in the header-file because I think that are too much parameters for the command line and it is easier to do it in json with an normal editor.

The goal would be to have a interface like:

'' python3 dbc2json.py -i  file1.dbc:hs:w  file2.dbc:ls  ''


Thank you very much
Thomas

-- 
Romain Forlot - Embedded Engineer - IoT.bzh
romain.forlot@... - www.iot.bzh - +33675142438 

cp ${WD}/low-level-can-generator/build/application-generated.cpp ../low-can-binding/binding

cp ${WD}/low-level-can-generator/build/application-generated.cpp agl-service-can-low-level/plugins 

Hello Walzert,

There is some ongoing work that has been a bit set aside to be able to develop plugins out of binding core project. So we are some kind of an in the between state.

So far, there isn't any handwork here but I had to check if there isn't any fixes and improvements to be pushed about the generator. This would explain why you haven't the same result.

Also the docs have to be updated indeed.

The agl-vcar-signals.cpp are a subset of signals defined in the default-signals.cpp

I'm not sure about your problem of your definitions vcan0 and slcan0. Can you send us the header, thanks.

Regards.

Romain.

Hello Romain,

I had the time to do work on that topic again.  I have to ask you some questions regaring that topic.

To follow my step I took that file https://git.automotivelinux.org/apps/agl-service-can-low-level/plain/examples/agl-vcar/signals.json (I wanted to see the right behavior before using my own JSON file).
And converted it with  low-level-can-generator  and the result was  application-generated.cpp  and that is different to the agl-vcar-signals.cpp seems to be some handwork right? Is there a exact discription what is necessary to change?
And  the old doc of agl-service-can-low-level tells to

cp ${WD}/low-level-can-generator/build/application-generated.cpp ../low-can-binding/binding

I think it is now (I made the really important information bold)

cp ${WD}/low-level-can-generator/build/application-generated.cpp agl-service-can-low-level/plugins 

is that right? And is default-signals.cpp  in agl-service-can-low-level/plugins just a copy of agl-vcar-signals.cpp ?

I added a "application-generated.cpp" file from me. And I found out that my definition of "vcan0" and "slcan0" in the header part is wrong and I have to use numbers like 0 and 1 (but I'm not exactly know what is the definition for that).


Thank you very much

Greetings
Thomas

-- 
Romain Forlot - Embedded Engineer - IoT.bzh
romain.forlot@... - www.iot.bzh - +33675142438