Return to Home

CANKing, Database Editor, advantages and limitations, software that does more from Partner companies

The CAN Basics Training Course provides a practical approach to understanding how CAN works. By giving real world examples, common practices, and an in-depth look at DBC files, Bryan Hennessy gives a real-world walkthrough of CAN. Presentation by Bryan Hennessy. Recorded as part of a ‘live’ training session in January 2019.

Video Transcript:

Bryan Hennessy: [00:00:00] So we’ve talked a little bit about CANKing. I’ve mentioned the Database Editor. I want to mention advantages and limitations of the Kvaser software. Kvaser is in the business of selling hardware. Our software supports are hardware. The software that we provide is software that’s pretty much necessary to play in the industry and sell hardware. You got to have drivers or the hardware doesn’t work. You got to have some basic applications and things to show the hardware works. We sell Memorators, data loggers. We got to be able to configure those. We got to be able to set those up. But the real brunt of the software that’s specific for a given industry or that’s detailed for a given application, the really good software comes from our partners. We’re not in the software business. We’re supplying software that allows our partners to be in the software business and sell our hardware. That’s the basic business model. [00:01:01] I call it software that does more from the partner companies. So we’ve talked a little about our software. We show some examples of our software here. So this is a cutout of my homemade hacked DBC file displayed via Kvaser’s DBC file editor. So you have a couple of things here. I’m not going to get into every detail of it. It does a lot. But I’ll just, again, give you the gist of it. So we would define some messages out here, or some complete messages. One of my messages here is the heading message. The other message is the rate-of-turn message. Well, we’ve seen both of those frames. We’ve seen those CAN frames in real life earlier, those two CAN frames. If I had all of my goodies and I didn’t have to bring my ski boots, I’d be able to show you some other stuff like system time and position rapid update messages coming out of my GPS which I left home. [00:02:00] Speed coming out of my little water sensor that can flip a little paddle wheel and you can see my water speed. A different message. Signed data, which actually comes out of a Memorator which is a t-program that I wrote to generate a message. I’ve actually got a t-program I can demonstrate you that does an ECU simulation with t-programming and generates messages that I invented. I just said, “Well, I’m going to write a t-program to demonstrate that a Memorator can be used for an ECU simulator.” What kind of data I want to send, well, I just pulled something out of the air and said, “I’ll just make a sine wave and I’ll just make a 100 sine wave and send that data via floating-point signal.” So I got a package that’s floating-point signal in a CAN frame. How do I do that? Well, I just do a DBC file and package it with a DBC file. So I did that. So that would be. But again I could do that because I do have a Memorator. So I can show you that one if you want. So down here in this block, I’ve highlighted heading here. [00:03:00] Down here this tells me, well, what signals are in the heading message. Well, the heading message, first of all DBC file editor has this little pretty window over here that just lights up what signals you’ve described. I’ve put the heading message in these two bytes. Actually, I didn’t. NMEA 2000 spec did. So, heading’s going to be in these two bytes. There’s something else up here in this byte, I don’t know what it is. There’s a lot more things down here in these bytes, I don’t know what they are either. I don’t really care because for my demonstration purposes I’m going to teach you about heading. So there’s a lot of information here but we’re only going to worry about heading today. So when you highlight heading, it tells you each signal that happens to be in heading. In the heading message it lights up down here. Inside of my heading message, I have a signal called Heading Magnetic because that’s what this is putting out, what the data is putting out, is the magnetic heading. [00:04:00] What is that signal? Well, it’s an unsigned integer. This is all stuff you can figure within your DBC file to describe your message. It’s in the Intel format. But you got to go back to digital computer invention history to really get a good feel for that. Intel and Motorola decided they’re going to transmit data differently many, many years ago, and one of them said, “We’re going to send the least significant byte first.” The other then said, “We’re going to be different. We’re going to send the most significant byte first if it’s a multi-byte message and a multi-byte value.” Just randomly we use Intel format that was decided by J1939 committees years ago. They’re using the Intel format, which is we’re going to send the least significant byte first. So I’ll show you why that’s important. We can’t figure out what the data is unless we know what format it’s in. This is a signal. It’s going to start at bit position eight and it’s 16 bits long. That identifies where it is [00:05:00] in the frame. We already start with zero when we’re counting digital stuff. So zero through seven is the bit positions. Then eight starts here. So we know where it starts and we know it’s 16 bits long. So we know where our signal is now and we know which byte is most significant and which byte is least significant. So we’ve just defined where our signal is within that data frame with a couple simple values. What do we have over here? What do we have left? We have a factor and an offset. In this case, offset is zero. If offset was other than zero, we would apply an offset to that value. But it’s zero in this case we’re having. We have a factor. We’re going to apply that factor and figure out what our heading is. Factor is just what it sounds like, it’s just scales, that value. So when I say a DBC file, the main purpose of it is to define the messages and then to scale [00:06:00] and offset the data. I’ve just shown you exactly what I mean by those three statements. This is an important slide. I’ll spend a little bit of time on this slide. So before I do that though, let me show you one other thing here. I’m going to actually minimize this so it’s not in the background. So we got our data clipping along here. The data is being displayed in standard text format. If you look at this box right here, this tells me how I’m going to display my data. I have a bunch of different options, I’m not going to get into them but will look at some examples and show you. I have a format that I can display my data and it’s called a DBC formatter. My DBC formatter CANKing actually will read your DBC file and will format your data according to your DBC file. So I’ve created this funny DBC file and I’m going to click that little box, [00:07:00] and what’s going to happen up here, look at my screen, is now you see my data in two different formats because I have two different formatter boxes clicked. Now you see my data in raw data format up here. You see my identifier, my flags, and my DLC, and then my data which is changing and my timestamp. But because I’ve got the DBC formatter box clicked, you also see it formatted according to my DBC file. This is the name of my DBC file right here. It’s a long name. I should have shortened it. It would be more understandable. But this is just a file with a dot DBC extension that’s on my PC. This is what I edited in my DBC file editor I showed you earlier. Heading Magnetic is the name of the signal I’m looking at. So my DBC file dot heading, which is “Heading” is the message, “Heading Magnetic” is the signal, and [00:08:00] there’s the value. So my DBC file is taking this text data and it’s converting it into this value. This message down here is my sign turn rate. I’m not going to get into that other than to show you that. When I turn the compass in the clockwise direction, my heading changes and my sign turn rate goes up positively. If I turn the compass in the counterclockwise direction, I get a negative turn rate, and you can always see my heading change out here as I turn it. Right now, I’m pointing it at about north. Let’s go to exactly north. We go this way. So there’s perfectly north right there. So this is a compass. Use to steer on autopilot and hundreds of vessels that have installed these on. While I’m doing that, the main bytes that are changing are here. We know those two bytes. We know how they’re scaled and we know how they’re offset. Somehow, [00:09:00] all of that information from the DBC is going to be used to calculate this value. Well, why don’t we see exactly how? Let’s use to calculate that value because it’s not very complicated. So I’ve grabbed here three different CAN frames and formatted them to be understandable. We have the raw data that I just showed you and then we have the interpreted data based on the DBC file. The first two CAN frames here were being put out by my simulator that I told you about, I created in a t-program. I’m not going to get into them other than to say my simulator was counting. Each time you just send for CAN frame, I incrementally counter. Then I was putting out a signed value here in a floating-point format. You had a question? Unidentified Man: Do you always have access to the DBC file? You mentioned the embedded processors and things. Bryan Hennessy: [00:10:00] No, you don’t. I’m sure that many companies that make an embedded processor they don’t even use a DBC file, they use the concept in some other format in an embedded processor. I mean let’s face it, there are smart sensors out there that use 8-bit processors, they’re certainly not going to use the DBC file, especially in a format that’s readable by an IBM compatible computer. Now they’d use it in some other format. So no, you wouldn’t. In the case of J1939, the J1939 standards committee makes a standard. It’s a very complicated standard .The J1939 committee does not make a DBC file. The industry makes a DBC file. So you go to one of our partners, you go to any other company, you can buy a DBC file. That’s intellectual property by that company. Most manufacturers, I can speak for PACCAR since I worked for them, we have a standard DBC file [00:11:00] that’s a J1939 that we bought from somebody. We have additional DBC files that have secret information in them for messages that we don’t want people to interpret. I mean a CAN bus is so dynamic that – I made this point yesterday practicing on this presentation – there’s so much information on a CAN bus in a vehicle, for example, that you might be interested in 2% of that CAN bus and never know what’s going on on the other 98% of the messages on there, and you may not have the keys to unlock what’s going on on the other messages on there. It’s just gobbledygook. It’s just hex data going by. That’s one of the beauties of the CAN bus, is you can be an expert on your segment and look at the other stuff all day long every day and never know what it means, because you don’t have the key, the DBC file. Here we have the key. We reverse engineer [00:12:00] that actually, because I didn’t have an official NMEA 200. So I just reverse engineered this, I hacked it basically. This one I invented so I didn’t have to hack. These datas I invented. So what I did here, for those of you who are interested, it’s a little more complicated, is I just calculated a signed value based on the number and I just set up a counter and I counted it from 1 to 100 and I just broke up a sine wave into 100 different increments and I encoded that with a floating point number. I’m not going to explain floating point today. I’d have to go back and research, I don’t remember. But floating point is a way of representing a positive and a negative value and scaling it the way you want it. I just created that. But this is the frame we’re going to talk about mostly. These are just example frames. You can see I’m counting. I’m off, so you can see I’m counting in hex because I went from 1.9 to 1A and the decimal equivalent of that, which my signal sample interprets this from 2.5 to 2.6, [00:13:00] pretty simple if you know hex data. This is the frame I’m most interested in. This is the frame put out by that compass. There’s the date coming out in the raw CAN frame. There’s the heading value that is interpreted, that the compass is transmitting at that time. This is a little snip from my DBC file editor that I showed you earlier. This is just describing heading magnetic signal. You’ve seen this before, I walked you through this. So how do we get from here to here using this information? It’s pretty easy. We know it’s Intel format, so we know it’s least significant byte first, most significant byte second. So this is read as 849C. 849C. Well, if any of you want to pull up your calculator on your PC, [00:14:00] I can do it, and go to programmer mode and type in a hex number of 849C, you’ll quickly understand that that converts to 33,948 decimal. It’s a simple hexadecimal conversion. So if we take that number, we know we don’t have any offset because it’s zero, but we have a factor. So we take that number and we multiply it by our factor. What do we get? We get that, don’t we? This is just a display that rounds it off. It’s that easy. We can now go from the voltages on a CAN bus all the way to meaningful data with what we’ve learned here. That means something. That means where I’m heading as I turn my compass. It could be oil temperature, it’s the same concept. It could be boost pressure in a heavy-duty truck. [00:15:00] It could be tire pressure. It could be anything. It could be any signal we want to define with a DBC file just like I defined a floating point sine wave signal here in something I invented. Unidentified Man: Who define the factor? Bryan Hennessy: Here? Unidentified Man: Yes. Bryan Hennessy: I just calculated it. Yes. If I bought an official DBC file for NMEA 2000 from Warwick or somebody who sells it, I wouldn’t had to. But I didn’t want to buy it so I just calculated it and figured it out. It was a learning curve for me. I actually didn’t have a full understanding of what a DBC file does and did. I kind of did but I wanted to understand it deeper, so I figured I’ll just hack my own and then I’ll really understand it. So I hacked it. I’ll give you all the stuff if you want it. I mean this just free stuff. This is just play stuff for me. So we’ve got through the physical layer. We’ve got through the data link layer. We’ve taken the data apart. We know what the data does, [00:16:00] at least in J1939. Now I can’t stress enough if we’re in CANopen, or we’re in DeviceNet, or something other high-level protocol. The identifier phase may be broken up differently, the data is going to be broken up differently, it’s going to mean different things, but we’ve seen an example, a real world example coming out of a real device that’s on the market that gives us data. So we understand the data. We pretty much understand what an application layer is, how it separates between everything else. What I haven’t gone into is transport protocol. So we’ll do that. But what’s the question? Unidentified Man: One more question. So, if you have various devices in the CAN bus, so we have various DBC files, correct? Bryan Hennessy: DBC file can explain every device on the network or any number of devices on the network. Most of the applications will allow you to load more than one DBC file in to describe. Unidentified Man: So, that comes back to the question, if you go to the CANKing, how do you [00:17:00] assign one DBC file to one of the datasets? Bryan Hennessy: Well, the way a DBC file does is you load more than one of them and hopefully there’s no duplicates in there. But if there are, most of the applications will tell you if there’s a duplicate definition of a particular CAN frame. Then we’re going to use the last one we get. We’re going to overwrite the first. Or they might say we’re going to ignore the last. I don’t even know. But that’s which way it is. But applications will usually, if they’re proper applications with proper documentation, specify which frame identifier they’re going to use in the case of duplication. There’s other questions? No. So we’ve covered everything. We’ve covered everything except [00:18:00] for transport protocol. We’ve talked about physical network sending 1’s and 0’s. We’re really clear on bit-wise arbitration. We’ve talked about data link layer defining the different pieces of the CAN frame. We’ve taken them apart. We know what they mean. We’ve talked very extensively now about the applications layer, in this case J1939, and how to translate data via DBC file into real meaningful values. One thing we haven’t talked about is this little blue box here, the transport protocol. So we’ll go into transport protocol now. Again, transfer protocol is different depending on what protocol are you talking about. Transport layer, I should say, is different depending on what protocol you’re talking about. Transport layer, the one I’ll talk about, is again the transport layer in J1939 or what they call it transport protocol. Unidentified Woman: But this DBC file, is that the key that you were talking about? Bryan Hennessy: [00:19:00] That’s the key. Unidentified Woman: If you have a DBC file, we’ll understand the data. So that’s the key? Bryan Hennessy: Yes, and that’s how the computer understands the data, is by looking at the DBC file. Yes.
Back to: CAN Basics Training: A Practical Introduction to the CAN bus > DBCs and Beyond