.DBC file import

Frederick Prigge 10 years ago in IQANdesign updated by Gustav Widén (System support) 2 years ago 16

It would be fantastic to have a script to import .DBC files that would generate automatically the GFIN/JFIN GFOUT/JFOUT as well as the associated JPIN/GPIN JPOUT/GPOUT. That would literally save be weeks of typing and may mistakes!

Good idea Frederick, At our office Wilfried is working writing CAN (Open & J1939) interface (Function Group) to set up communication with other Parker products like MB LV Invertors, AC10-AC30 690 Frequenty controllers, CAN pressure sensors, . It is a lot of work and script would really help

I'd also support this idea if it was implemented. Manually taking a DBC and translating it is quite time consuming, and as Frederick says, it increases the risk of making a typo while translating.

Any chance there is progress implementing .dbc import

Still open but not planned for a specific release unfortunately.

Any news on this? It still is a missing feature to me that is much more important that Tablet support or new GUIs for the design tools! Thanks


Funny you should ask, this has just been started. We're hoping to have it ready for IQANdesign 5.02, which is planned for release early 2018.

Hi Ulrik, Is this still on course for release early 2018 as I have a customer requirement for CAN .dbc file unpacking


New CAN database feature with support for .DBC file import implemented in IQANdesign 5.02.


CAN Database is a very nice feature, and the description box on the bottom is also a nice feature. But I would like the option to import the text from the description box to the description field for the JPIN and JPOUT. That way I can read about the status when monitoring the channels.

I have done this manual and its to me very helpful. I also added some extra info so don't have to click on the channel to know SP Number and such.

I have used the dbc import quite a bit, here are my comments:

  1. it would be really helpful if the scaling and signage would be automatic in generic CAN parameters, a bit like they are in J1939 parameters. We still need to manually generate a math channel to scale those values while all the info is in the dbc.
  2. As posted above, it would be nice that the comment field of the DBC for each signal and frame could be copied to the description box of the signal / frames.
  3. The DLC for generic frames is not right. All my output frames get created with a DLC of 8, but they are in fact shorter.
  4. Same philosophy as the scaling, we usually create a state parameter that replicated the enumeration values in the BDC for state signals. This should also be automated.
  5. When importing frames that have "holes" in the signal layout, the converter generates garbage.

Unrelated to the DBC import, the page bits (mux) are limited to the first 32 bits of payload. believe it or not, some components use the last bits or somewhere else in the 8 byte payload to mux the frame! Please increase the mask size to 64 bits!

Great feature and looking forward to see it improve. It has already saved us may days of labor! Thanks!

Thanks for the feedback Frederick. 

The DLC issue seems straight-forward, but do you have an example of a DBC with the "holes" you describe that you can share? If you don't want to post it directly on the forum you can send it to https://iqan.sharefile.com/filedrop

I agree with the suggestion Jonas made some months ago that text import to the description field would be a really nice addition. Automatic creation of MAC and SP channels is also an interesting suggestion. 


I'm glad to hear that IQAN is finally taking steps to utilize CAN databases represented as .dbc files, like almost all of the other vehicle CAN network users are using, (GM, Ford, BMW, Mercedes, Daimler-Chyrsler, John Deere, Caterpillar, Bosch, etc), as well as software & CAN development tools, such as (MatLab/SimuLink, Vector, Peak Systems, Kvaser, IXXAT, Bosch, Freescale, High Tech, VehicleSpy, etc)

I know of other ECU manufacturer's that use the same Infineon CPU's as IQAN.   Some of these Infineon chip users have created scripts to merge the info from a .dbc directly into the Infineon code development environment. 

See:  Infineon.com Forum: Generating C-Code from Vector CANdb++ .dbc files

In other words, the work has been done.  It sounds like it is just now being ported into the IQAN development platforms.

Being able to use .dbc's is a big deal, and is getting bigger due to distributed controls being spread across both CAN and Ethernet on a single controller, such as might be possible with the MC4x products.  One can now buy CAN .dbc protocolinterpreter addons for Wireshark, possibly the world's foremost widely-used network protocol analyzer (and it's FREE!)

You can then use your USB-CAN tool of choice, a CAN .dbc file, and Wireshark to see how the data is interacting . This is extremely useful when developing products which utilize other manufa turers ECU's in conjunction with IQAN modules, all of which have both Ethernet and CAN buses.  This allows one to see time synchronized data from both disparate

When is this going to be available for IQAN4?  

Fixed issue with importing, see http://divapps.parker.com/divapps/iqan/Downloads/IQANdesign%206/ReleaseNotes6.00.48.htm

47782Errors when importing DBC files
For motorola byte order the DBC file was interpreted incorrectly causing the offset to be wrong.

In the vector dbc tool it is possible to use motorola byte order for parameters spanning over multiple bytes without being byte aligned. This is not possible in IQAN. Added a check for this when opening the dbc. A dialog is shown stating that some signals was not imported if such signals are found.

Is there a reason why IQAN cannot import parameters spanning over multiple bytes without being byte aligned?  Can this be fixed?  If not is there a log file that says what parameters were not imported?

My guess is that the parameters are set as Big-endian in the DBC? 

GPIN/GPOUT are Little-endian by default, and the property for changing byte order is only available for byte aligned parameters. When the prococol requires a different byte order, one has to implement this in the application with additional math channel. (there is and old feature request on this here: Byte Order for bit-sized CAN messages / Software / IQAN)