Please note that this feature has to be bought first. Contact your vendor to obtain a license. Without a license, it is not possible to export into a DBC file.
Disclaimer!We try to adhere to the DBC file format as well as possible. If you find that an exported DBC file from our program, please contact the technical support from your vendor with your project, the DBC file and a description what is missing or wrong. |
To start the export, open the dialog under the menu Communication -> Import-Export -> Export DBC File.
Note that the dialog can only be opened with an opened project.
The export process is done in two steps.
In the first step, a CAN protocol needs to be chosen and a DBC file name is given.
In the second step, the CAN messages and variables to be exported are selected.
1. Select Protocol and File for Export
If no CAN protocol has been added to the project, an export of a DBC file isn't possible, so first at least one CAN protocol has to be added.
The Configure ECU(s) dialog can be reached with the button "Configure ECU(s)...".
If there are several protocols in the project, one has to be chosen for the DBC export, i.e. from which protocol the CAN mappings should be exported.
A folder to save the file in has to be selected. Then a valid file name has to be given. The file name needs to be complete, i.e with the extension, e.g. "test.dbc".
If a file with the same name already exists, a warning will be displayed that the existing file will be overwritten by the export.
Once all settings have been made, click Next to continue.
The export process can be canceled at any time by clicking Cancel.
2. Select CAN Messages and Variables
In the second step of the dialog the CAN messages and variables for import can be selected. To select a CAN message for import, activate the check box in the Select column in the upper table of the dialog. With Select/deselect all CAN Messages, all messages can be selected or deselected at once.
If a CAN message cannot be exported into a dbc file, the CAN message will be displayed with a red error icon and cannot be selected.
The restrictions for an export are:
•No String variables must be in a mapping. Strings are not supported by Vector
•No Delimiter-based mappings can be exported. Delimiter-based mappings are not supported by Vector
•Multiplexer-Messages are only available for CANFreestyle and J1939 protocols, but not for CANopen
•Messages with same CAN-ID but different Multiplexer-Positions can not be exported. This is not supported by the DBC format
When a CAN message is selected for import, the according variables are automatically selected for import, as well.
The table below the CAN messages shows the mapped variables of the currently selected CAN message.
Note that the variables cannot be de-selected and no properties of the variables can be changed.
The export process can be finished by clicking Finish.
Then a dialog will be shown with an overview of what has been exported.
The export process can be canceled at any time by clicking Cancel.
The following properties of CAN mappings are exported:
All protocols:
•Type (RX/TX)
•Producer of the message (for Receive the "Receive From" value will be set, for Transmit the device will be set)
•Consumer of the message (for Receive the device will be set, for Transmit the "Transmit To" value will be set)
CANFreestyle:
•Rx/Tx: The property CAN ID(0x) is used for CAN-ID
•Rx: The property Receive Timeout is saved in attribute GenMsgCycleTime
•Rx: The property Enable Request is saved in attribute GenMsgRequestable
•Tx: Transmission Period
CANopen:
•Rx/Tx: The property COB-ID is used for CAN-ID
•Rx/Tx: The property Event Timer is saved in attribute GenMsgCycleTime.
•Tx: Event Timer
•The CANopen address of the device (Node ID)
•The Heartbeat Producer Time
•The Heartbeat Time
•SDO COB-IDs
•The SDO Timeout
J1939:
•Rx/Tx: The properties PGN Priority, PGN and the source address is used for CAN-ID (as described in J1939 standard)
•Rx: The property Receive Timeout is saved in attribute GenMsgCycleTime
•Rx: The property Enable Request is saved in attribute GenMsgRequestable => It is only set to true if also the property Use Standard Request is selected.
•Tx: The property Transmission Period (in ms) is saved in attribute GenMsgCycleTime
•The Preferred Source Address
•The Terminal Name and address claim properties
The following properties of variables are exported:
•The name of the variable is used for signal name. NOTE: EMPTY_SPACE will be converted to _ because it is not allowed in DBC-Format
•For constants, the prefix CONST_ is used with the variable mapping size, e.g CONST_8
•For constants, the suffix __n, with n starting at 1, is used if more than one constant is used in the source project
•The name of predefined variables e.g. @AlarmShow is not valid in DBC-Format. (the @ sign is a delimiter) so the prefix __AT__ is used instead (e.g. __AT__AlarmShow)
•The Scale and Offset2 of variable mappings is used for setting Scale and Offset. (Offset1 will be exported as a user-defined attribute that won't be used in Vector)
•The property values Min and Max of the mapped variable will be set as Min and Max. NOTE: If the variable mapping does not use the whole length of the variable, the Min and Max value is set appropriate to the mapped length. For constants the Const value is used for Min and Max
•Unit is currently not supported and will be always set to EMPTY_STRING
•The owner will be always set to Vector__XXX (default owner)
FAQ
What about multiplexer messages?
The DBC format supports multiplexer messages, and our program supports them, as well. For multiplexer messages to be recognized as that, messages that use the same CAN ID (which is otherwise forbidden in Vector) need to have a identifiable multiplexer byte, i.e. a constant in the same position in the mapping. Otherwise messages with the same CAN ID cannot be exported.
If there are several constants in different positions, it cannot be detected which should be used for the multiplexer byte, so the export will not work, as well.