Applying a J1939 DBC file and building a simple test script in CanKing

In the previous post I introduced some of the free software downloads from Kvaser, and gave an example of how to use some of these tools for learning about CAN, and for CAN development and test projects while at home. There is no specific hardware required for this, just a computer. The primary software tools are Kvaser CanKing and Kvaser Driver for Windows.

What we accomplished in the last blog was to send random data between two virtual CAN channels that the Kvaser Driver for Windows creates when installed. We picked random addresses and let the program pick some random data. Today we will explore ways of using this ability to learn SAE J1939 CAN Frame formatting and create a method for testing an application. For now, we will keep using the two virtual CAN channels installed with the driver.

If you would like some study material to prepare for this blog, search Kvaser.com for CAN Basics, or visit https://www.kvaser.com/course/can-basics-training-a-practical-introduction-to-the-can-bus/ for a video introduction to CAN. You can also look at An Introduction to J1939 and DBC Files, also available on Kvaser.com.

To follow along with actual data as I go through this blog, you will need to have a .dbc file available to load into CanKing, or you will need to create one. Creating a .dbc file for just a few CAN messages and signals is not that difficult with the Kvaser Database Editor 3, available free at https://www.kvaser.com/download/. Creating a .dbc file will not be covered in this blog.

Start by opening Kvaser CanKing using the 2 CAN channels template, as in the first blog of this series, then go to View and add the History List window and Times Transmission window to your desktop as before. Creating the CAN message is where most of the complexity will be, so we’ll start with the message I copied from a recent article on J1939 tools. Here is a raw message that I am going to use:

This is a message as received in CanKing, and is called the Electronic Engine Controller 1 message, identified as PGN 61444. The signal we will manipulate within this message is Engine Speed, identified as SPN 190. To do this we first need to break the message down into the Identifier and the data segments. 

To show how to construct the identifier from the J1939 data above, here is a cut from the CAN Protocol Tutorial, Higher Layer Protocols, found here: https://www.kvaser.com/about-can/higher-layer-protocols/j1939-introduction/.

This is a 29-bit extended identifier, so we know the following from the information in the frame, as displayed in CanKing:

Priority = 3

Reserved Bit and Data Page = 0

PGN = 0x0F004

Source Address = 0

Combining all this information into a 29-bit identifier and displaying it in hexadecimal format gives us 0CF00400, so plug this into the CAN Identifier box in the message window, putting the small “x” at the end to indicate Extended identifier format. See the next figure below.

If you are having difficulty understanding how I came up with this hexadecimal number from the bits as displayed in CanKing, start from Source Address on the right, and work right to left. Remember that the identifier must be 29 bits, or seven nibbles plus one extra bit on the left. The Priority is what makes it difficult, because it straddles nibbles 7 and 8. A frame with a priority of 3, like this one, always starts with an 0C and has the form 0Cxxxxxx, while a frame with priority 6 has the form 18xxxxxx, and priority 7 would be 1Cxxxxxx.

Next, we know the Data Length Code (DLC) is 8, so enter this in the DLC box.

The eight data bytes are as listed in the CanKing frame above, 60  7D  84  50  14  00  F0  84, so enter these as Byte 0 through Byte 7, reading from left to right. The end-result is the CAN message window as shown below, with the identifier and the data entered, ready to be sent:

Next, we need to load a .dbc file that describes the data we’re ready to send. I have a partial J1939 dbc file that I use for things like this, so I am going to load it into CanKing. To load a .dbc file into CanKing, go to the Select Formatters window and activate and select the J1939 Formatter. You can now double-click on the J1939 Formatter to open the Select Databases window as shown below.

In this window you can see that I have loaded a .dbc file into CAN 2. I have also selected the settings I want to use in displaying the data. Since we plan to transmit the message from CAN 1 we will receive it with CAN 2, and this is where we want to decode the message using the .dbc file.  We’re now ready to test our system. Select Start Run in the Kvaser CanKing window, then click on Send in the CAN Message 1 window. If everything was set up correctly your Output Window should now look like this:

This Output Window shows four lines of data, plus all the signals within the message decoded per the .dbc file loaded into CAN 2. We know data was transmitted on CAN 1 and received and decoded on CAN 2. The reason we’re seeing four lines of data is that we have two formatters selected in the Select Formatter window, the Standard Text Formatter and the J1939 Formatter. Each formatter produces one line for transmitted data and another line for received data. Starting at the top, the first line shows the Standard Text Formatter transmit line. Below that is the J1939 Formatter transmit line, and since we don’t have a .dbc file loaded into CAN 1, it does not decode this data and just shows it as raw hexadecimal numbers. The third line shows the Standard Text Formatter receive line, which looks just like the Standard Text Formatter transmit line, as it should. The fourth line is the important one, showing the J1939 Formatter receive line with all the signals in the message decoded and displayed. Here are the signals and their values as decoded:

To summarize what we have done to this point, we have manually created a J1939 Electronic Engine Controller 1 message within the CAN Message 1 formatter box, loaded a J1939 .dbc file into CAN 1, sent and received the message over the virtual CAN buses within the Kvaser Driver, and decoded the message with the .dbc file.

The next step is to make something more practical out of all this data manipulation. I’m going to identify the Engine Speed signal within this program, and then manipulate it across many messages to create a simulated engine speed ramp. I’ll capture this data in the History List window then used the Timed Transmission window to play it back as a continuously changing engine speed. A practical application for this would be in a test circuit where you wanted to control engine speed in a simulated environment and use this to test the response of a different device. You could create it and test it here, then using the Save feature in the History List window, you could save this test and play it back later to test the response of a different application. You could also play it back later through a Kvaser hardware interface, and test the response of any device on the same CAN bus. Any signal you create and test over the virtual device is available to you through a Kvaser interface, and can be transmitted to any device you like.

We know from the J1939DA that bytes D3 and D4 are the Engine Speed signal and D4 is the MSB (Most Significant Byte). Follow these steps to create an engine speed ramp test signal:

1. Clear the History List window by right clicking in the window and selecting Clear.
2. Start a new run by clicking Stop then Start Run in the Kvaser CanKing window. This will reset the timer field.
3. Click Send in the CAN Message 1 window one time. This will put one message into the History List.
4. Change Byte 4 in the CAN Message 1 window from $14 to $15 and click Send again.
5. Repeat this sequence as many times as you like to create a history list of a ramping engine speed.
6. When you have the data you’re interested in, click Save in the History List window and select a location and file name.

To the right is a view of my History List window with the engine speed ramp that took RPMs from 650 to 1738.

You can use this manual method to manipulate most CAN data that is described in a .dbc file provided you have access to the .dbc file. If the signal you want to manipulate is part of a larger message that uses Transport Protocol, this task gets much more difficult.

Kvaser has many partner companies producing powerful CAN analysis and simulation software that can do much more than what I have demonstrated here. These companies and their products can be found on www.kvaser.com under CAN Software/Partner Directory. The tools I’m showing here are good for learning about CAN and maybe performing some simple simulation and validation tasks. I hope you find this blog useful for whatever work you are doing with CAN. Stay tuned for more in this series!