BusMaster – Building a CAN database from a log file

5 min read

In this article, we will look at a few simple tips to help start building your own CAN database. We’ll start with the BusMaster log file that we took from the stand-alone module in the previous article. We will import this to Excel to do some initial data mining. Then we can start to construct our own CAN database and put it to use in a BusMaster configuration.

Stand alone module log file

At the end of the previous article, we connected directly to a stand-alone module and woke up the FCDIM. Then, we could interact with the display screen and see some incoming messages from the module, outlined in Red above.

While there are filtering tools in the BusMaster message window, they only work when communication is stopped. Even then, the performance is mixed. I certainly experience problems with filtering by the ‘Tx/Rx’ column. To avoid this and give some flexibility, I usually import the log into Excel.

Importing a log file to Excel

Rather than risk creating a long and tedious thread about the fundamentals of data import in Excel, I’ve created a separate post. The article deals with importing as a text file, building structure and cleaning out some ‘ghost’ messages. It will also introduce filtering and how to use it to investigate the data. If you need to, have a read a pop back.

Read: Step by Step – Import a BusMaster Log in Excel

With the log from the stand-alone module imported and filtered, you should end up with a shortlist of addresses on which the FCDIM is transmitting data, as shown above. We can now start using this list to populate our CAN database.

A CAN database (CANdb) introduction

A CAN Database (CANdb) is a structure for describing the content of a message as defined by the CAN specification. A CANdb file usually has a ‘.dbc’ file type. A CANdb describes every module by its addresses, every frame that address will send and every signal contained within the frame.

It is unusual for a single module to need to use every single message on the Bus, all 6500ish of them. For example, The HVAC control doesn’t need to know how much fuel is being injected into an individual cylinder in the engine. The CANdb also describes the relationships the modules have to each other’s messages, and perhaps critically, if module B needs to receive a message from module A. As you might imagine, this data is not shared by manufacturers or suppliers.

Making a CANdb in BusMaster

BusMaster uses a simplified version of the CANdb in a ‘.dbf’ file type. By creating our own CANdb, we will be able to identify messages sent by a specific module based on its address. When we start to look for changes in the system, we can quickly find the changed values if we already have the address of the module we expect to change.

With BusMaster open, select ‘Tools’, then ‘CAN DBF Editor’, then ‘New’ to start your own CANdb, as shown above. Give it a descriptive name and save it somewhere you’ll find it again. Personally I try to save all my BusMaster files in one folder for each configuration I create.

Once the new database is saved, you’ll want to start adding messages, to do this right click on the database name and select ‘New Message’.

Next, enter the message details. You can give the message any name you like, but it really needs to describe the module that is sending it. In this case, we will call it ‘FCDIM_a’. As we already know that the FCDIM sends data on multiple messages, we need to give it a suffix. I like to give alphabet suffixes rather than numbers, and I will start with ‘_a’ being the lowest address. Remember that list from the Excel filter? The lowest value was ‘0x278’, so this becomes our message ID. We also saw in Excel that the length of the message was 8 bytes, so we can enter that too.

We can build up our CANdb to include the nine addresses we have identified as coming from the FCDIM. At the moment, we have only given the message a name and have not identified signals within it, but we will cover this in a later topic.

Associating our CANdb in BusMaster

Within the BusMaster, we can use this database by associating it with the configuration, as shown above. Once the ‘dbf’ file is linked in BusMaster, we will automatically start to see the address of the known module replaced with its name.

Straight away, we will start to see a benefit from having rich text names. Not only can we now relate a message with a module, but we can see duplicate messages we are transmitting from our log file.

In theory, if we were to take every module from a car, wake it up on the bench and associate the message address with the module, we would have a pretty big CANdb. But the link between the message address and the module is only a small amount of the database. It would require a lot more work to identify what each byte in the message controls, and we could make only a guess as to the dependencies each module has on a particular message.

We now have a start point for investigating the communication between modules. The database will allow us to check if a module is communicating on the bus, a very useful diagnostic tool. We’ve also worked with CAN networks enough to understand how the messages are formed and how they flow around the network.

The end of the Series

This is the last in this set of CANBus articles.

But it’s not over until it’s over!

To realise some of the extra features we want to use on the FCDIM, we need to understand what they are and what sort of messages they might include.

We now have enough knowledge to start creating our own hardware. That might come in handy if we want to start quickly interacting with messages on the bench.

Perhaps most importantly, we will have to start considering the Car Configuration File, which could get complicated.

So come back for future articles on the Gen2.1 system and consider subscribing by email or Facebook to receive notifications on new posts.

Thanks for sticking with me to the end. I hope you enjoyed and learned something from this series.

M

NEXT –
PREV – Import a BusMaster Log in Excel

Back to Diagnostics Articles
Back to Electronics Articles