Interpreting CANdb signal configuration

[Kamen]

I would like to know how to interpret the scaling of a signal defined in a CAN message in the case where the data type is signed. For example, let's take this definition, taken from a production ECU:

SG_ mech_pwr : 24|10@0- (1,0) [-500|500] "kW"

The signal type is "signed" (the "-" after the @0), is mapped to 10 bits (thus unscaled values can be from 0 to 1023), has a scaling factor of 1, and a scaling offset of 0 (the "(1,0)" part). Normally, you would take the formula "y = ax + b" (cf. NI-MAX) and you would map an unscaled value of, say, 750 to y = 750 * 1 + 0 = 750. However, the provided boundaries suggest that the range for this signal is -500 to 500, thus you'd think in the above example, y = 250, rather then 750. Not to mention the remaining 23  values (1023 - 500 - 500 = 23) - where are they included in the calculation? Is the value centered, or does it start from the lowest boundary? There is nothing explicit in the CANdb definition above (or in the rest of the dbc file) and the only way to interpret it this way would be through convention. I don't think it is by using the range because it is optional (and not enforceable), so there must be something else. Does anybody know?

Also, the default value is shown in MAX as 0.000000, but I see noting about that in the definition above, either. It seems like this is simply the data type default, but how would it be specified explicitly?

And, one more - in MAX, the "data type" combo-box has the "IEEE float" option (does not apply to this signal), but in the CANdb files I only see the "+" and "-" options. How is that deduced? I haven't found an example of that, but maybe my CANdb are old. I realize the CANdb is a multi-decade evolution and there has been a lot of compromises to accommodate backwards compatibility, but things can get really obscure with it.

Here is one resource that seems to be a result of an attempt to reverse-engineer an older version of CANdb: DBC spec

Kamen

[Hooovahh]

Are you trying to write a DBC parser?  I'd highly recommend you just use one already done for you.  I use the XNet drivers to read the parsing information in a DBC and then can read out the scaling information using the API provided by NI.

Here is some example code I posted a while ago which converts raw frames to signals, and signals to raw frames given a DBC.  The scaling part is able to read the information from the DBC by using XNet's API to import a DBC, and then read the information which is then used to scale the data.  This database can also provide information like comments, and default signal values.   As for parsing the DBC file itself I'd void it just due to the amount of work involved, and the error if you don't implement some lesser known feature of it, like channel Muxing.

If you do end up making a DBC parser feel free to share it with the community.  I'm obviously a fan of XNet but an open source alternative to the file parsing process is welcome.

[Kamen]

I will, eventually, be writing a CANdb parser, but for now I just need to design my software in a manner that can handle the various situations that may arise with customer databases. I don't know that I can trust a third party for the parsing, and although I will also look into licensing something from Vector, I will certainly be implementing a two-step import routine, where the user will have a chance to review and edit the configuration of each signal. While most other settings are rather straightforward to interpret, and will need user intervention anyway, mostly because even today's version of CANdb is rather primitive, the issue of scaling remains too ambiguous. As an illustration of my point: the signal data type used to be just unsigned or signed integer, and then they seem to have added some floating point type, while my software supports other data types, such as enumerations, Boolean and text. For example, if the signal bit length is one, it is obviously a Boolean. Another attribute that is much more advanced in my software is the actual support of units; with CANdb (and any other software I've ever seen), channel "units" are just a string that is appended as some sort of descriptive attribute. In my software, the resulting channel actually carries a full physical quantity attribute, with its physical dimension and selection of units (all user editable), so conversions, calculations and compatibility checking are automatically handled. This is why the manual review/override step could never truly go away, but I just want to save some of the steps, if possible; like the scaling, which has no reason to be complicated. And this contradictory use of scaling parameters that I see is just one example of it.

I appreciate your effort to help. I'd hate to take more of your time, but one way to do that would be to do some "reverse engineering" of XNet's approach. I understand it has a way to edit dbc files (i.e., export to dbc, unlike MAX), so you could rather easily set a signal default value (if it's one of the editable attributes) that is not the data-type's default value, and see if it shows up in the signal definition. Testing the signedness of a signal would be tougher as you'd need to simulate some CAN input (to verify the actual scaling), but you could see if the XNet parser has a problem with some contradictory settings, like a signed integer signal having a range that is unipolar or a scaling offset that explicitly defines its polarity (e.g., a SG_ mech_pwr : 24|10@0- (1,-500) [0|1000] "kW").

Kamen

[Hooovahh]

---

@Kamen wrote:

I don't know that I can trust a third party for the parsing,

---

But you can trust a 3rd party for your closed source programming language?  Or operating system?  Or microcontroller embedded in your CPU which runs closed source software?  It's clearly your call I just find it odd this is where you draw the line.

XNet could handle the two-step process you suggested.  Perform an import, and then edit the database (which leaves the DBC untouched) and then use the edited database for scaling.  XNet has an API for database manipulation and examples too.  NI handles the datatype issue by having everything be a double.  If you want to know the string value of an enum you can read what the lookup table is for the signal and get the string value.  The example I linked to allows for reading and writing CAN signals using strings too.  This does come with one known limitation.  No single signal can be more than 52 bits because if it was it couldn't fit in a double.  If this is ever the case you can try to wrap your own function to handle it, or just use the frame API which.

I'd avoid messing around with units until the values are to be seen by the user, and what you are describing sounds more like a higher level thing that could be handled separately from the DBC parsing.  You could of course get units in there but if I'm looking at a signal's value and it seems weird, the first thing I'm going to question is the scaling.  I'd also avoid it due to others individuals that might be using Vector or Intrepid and want to see values in the same units.

I'm unsure how XNet handles scaling things it can't scale properly but you can test it out to see.  It might be documented in the XNet manuals somewhere.

[Kamen]

---

@Hooovahh wrote:

---

@Kamen wrote:

I don't know that I can trust a third party for the parsing,

---

But you can trust a 3rd party for your closed source programming language?  Or operating system?  Or microcontroller embedded in your CPU which runs closed source software?  It's clearly your call I just find it odd this is where you draw the line.

I'm not sure what made you believe I was going to trust any third party - I trust no one, this is why each signal will be scrutinized and it will ultimately be the user's responsibility how the signal definition will translate into a channel in my software. I wouldn't even "trust" the first party - Vector - as the possibility that someone decided to get creative with their interpretation, always exists. What matters is standardization and the standard is the platform that will be used for all the data processing, which is my software. This is why I will do the conversion to the data type system that my software supports - once in there, channels need to have the proper types to ensure compatibility, correctness, the guaranteed resolution (e.g., integers have 64-bit storage type) and benefit from strong typing. For the same reason, units are interpreted the way they are - if properly done, it ads the protection of correctness-checking (e.g., you can't add channels with incompatible types in an expression), and it allows for the unrestricted (and always proper) conversion of units at the user-end.

The reason I'm trying to figure out how CANdb defines the scaling in case of signed integers (or any other types, for that matter), is to see who much of the parsing and conversion I could handle automatically. As I said, everything will ultimately be reduced to the consistent interpretation of my software, and it will be clear who's responsibility it was for the chosen approach (including scaling), but if I could find what the logic behind the CANdb conversion is, and it is consistent, I could save them some effort by suggesting the proper approach.

Thank you for your efforts! I wish there were discussion forums at Vector, so I don't have to annoy slightly unrelated forums, but short of trying CANHack.org, I haven't been able to find any suitable ones, so far. 

Kamen

[Hooovahh]

---

@Kamen wrote:

---

@Hooovahh wrote:

---

@Kamen wrote:

I don't know that I can trust a third party for the parsing,

---

But you can trust a 3rd party for your closed source programming language?  Or operating system?  Or microcontroller embedded in your CPU which runs closed source software?  It's clearly your call I just find it odd this is where you draw the line.

I'm not sure what made you believe I was going to trust any third party - I trust no one

---

I assumed you were writing LabVIEW software, made from a proprietary closed source programming language by NI, running on Windows a proprietary closed source operating system made by Microsoft, on an Intel based processor with custom microcontrollers running closed source software.  That's where my comment about drawing the line on who you trust came from.  If you don't trust any of them I think this is way more challenging than I first suggested.  Sorry I can't help any further with parsing and scaling, other than to suggest XNet is the solution I've chosen.

[Kamen]

---

@Hooovahh wrote:

---

@Kamen wrote:

---

@Hooovahh wrote:

---

@Kamen wrote:

I don't know that I can trust a third party for the parsing,

---

But you can trust a 3rd party for your closed source programming language?  Or operating system?  Or microcontroller embedded in your CPU which runs closed source software?  It's clearly your call I just find it odd this is where you draw the line.

I'm not sure what made you believe I was going to trust any third party - I trust no one

---

I assumed you were writing LabVIEW software, made from a proprietary closed source programming language by NI, running on Windows a proprietary closed source operating system made by Microsoft, on an Intel based processor with custom microcontrollers running closed source software.  That's where my comment about drawing the line on who you trust came from.  If you don't trust any of them I think this is way more challenging than I first suggested.  Sorry I can't help any further with parsing and scaling, other than to suggest XNet is the solution I've chosen.

---

That's alright, people make the wrong assumptions all the time! 

Kamen

[Hooovahh]

Oh in that case then file parsing is the least of your concern.  Start with a bare microcontroller.  While these can still be closed in their design an xray and independent review can confirm it does what it says and nothing else.  If you don't trust that then you can contract a company to design a custom built ASIC.  If you don't trust them then you can make your own processor out of transistors.  Then start writing assembly.  You'll probably want to write some kernel software stack to initialize hardware like a keyboard mouse, HMI or whatever else the user interacts with.  PS2 keyboard is probably the easiest, but if you don't trust that an embedded key logger is installed, you'll need to make your own out of switches and a muxing chip.  What is the display?  Lots of data sheets and manuals to write code to display things.  Some smaller TFT displays work pretty well but may take a decent amount of processing power.  I've never driven a full size display with something so under powered but I think an FPGA can do the job of displaying via VGA.  Not sure how to design and build an FPGA if you don't trust Xilinx.  How are you accessing the text files?  SD card with FAT16 would probably be the best since it is older and pretty well known.  There are a few SD to SPI or I2C interfaces and you'll need to write the file I/O stack manually by referencing the chips datasheet.  Before that you'll need to write the SPI and I2C interface.  Then you can start figuring out the parsing and scaling information.  The CAN part is actually easy enough, the MCP2515 and MCP2551 allows a micro to talk to CAN via SPI.  Several datasheets later you can read/write CAN.  I'm not an expert in these fields but I'd estimate a few years to do it this way.  

In the future be sure and mention the hardware and software platforms you are running on so wrong assumptions aren't made.

[Kamen]

There's that and there's reality. "Trust" can be imagined to be a lot of different things.

What I wanted to know had nothing to do with the specific platform I use; I only mentioned that for some context, but it's irrelevant. I don't care who responds, maybe someone else who knows will see this and will respond. CAN communications are not that popular and trying in a lot of places seems like a good option.

Kamen

[Minions]

Obviously, you must walk or bike everywhere.  CAN communications are used in almost every vehicle for something that is NOT that popular.

BTW: If you don't trust any response, then you shouldn't be surprised not to see any future responses.  Don't bother responding, don't care...