XNET DBC Enums

[blackburnite]

I'm going to guess the answer is no but does anyone know if there is any straightforward or at least workable way to maintain some form of signal enum values from a DBC file when working with XNET instead of just logging the numerical value of a signal, the best I can figure is parsing the DBC and writing the value enums as channel properties in my TDMS log.

- Will

[Hooovahh]

I'm not certain I fully understand your request.  At first it sounds like you want an enum that is the signals in a database.  To that I say you could write a tool that generates an enum based on a data base.  But I much prefer the XNET I/O controls and constants that can display a drop down of options.  This can be used like a string.  I believe all string functions work with it, and I think you can even use it on a case selector terminal.

Then you talk about logging the numerical signals which is where the confusion comes.  What do you mean?

[blackburnite]

I want to be able to maintain the value description enums in my DBC file.  For instance if I had a signal "State" with several states "Idle, Run, Initialize, and so on", when I look at my final log file, I would like to be able to see that "ECU A was in the Idle state at 10 sec and then switched to the Run state at 15 sec".  

Right now because XNET reads and write signal values as a number, what I get is a log file that says "ECU A was in state 1 at 10 sec and the switched to state 2 at 15 sec" where state 1 = Idle and state 2 = Run.  This is close, but for the people who are ultimately going to be reviewing these logs, they want to have that enum value right there in the log rather than having to look up what the numerical value corresponds to.

So what I need is a way to re-associate those numerical values with the description of what each of those values actually means.

[Hooovahh]

I'm not certain because I've never used it, and I don't have a database right now that has enumerated values, but I think you want the Database Get DBC Attribute, with the mode set to Get Signal Value Table.  This should return all the possible value name pairs.  Get Enumeration might also be useful.  In any case the enumeration information looks to be accessible, so you can read it, then write that string to the log instead of the value that represents it.

[blackburnite · Accepted solution]

I ended up dropping the CAN signals from my TDMS log, using it instead as a general system log and created a seperate logger to write the CAN data in Vector ASC format so I can just associate the DBC file with the ASC file when it is loaded in CANape.  As you mentioned, getting the enumeration info was doable but the TDMS format doesn't have the support for that type of logging.

[Bala_S]

Isn't it ridiculous that such critical information is unable to be handled by XNET. These enumerations are as valuable if not more, for some signals than their raw numeric values. How long will it take for NI to put in this basic functionality that has been around on every other system for decades. Its infuriating.

[Hooovahh]

---

@blackburnite wrote:

 As you mentioned, getting the enumeration info was doable but the TDMS format doesn't have the support for that type of logging.

---

Oh sure it does.  TDMS can log in many data types.  The way I handle this is I have a group called "Periodic Data" and in that is a channel for each CAN signal I want to read as doubles.  Then on test start I figure out what signals have enum values.  For the ones that do I then create another signal named <Signal Name>_String, which logs the value as a string value.  That way when the log is complete I have double values for all signals, and strings for those that support it.  When I want raw frame data I log it into a separate group and channel, that then gets converted to a BLF afterwards.

As for display purposes, I show the double values, unless the signal supports enums, and then I will show the string representation.  They all end up in a table so they will be a string for display anyway.

@Bala_S wrote:

Isn't it ridiculous that such critical information is unable to be handled by XNET. These enumerations are as valuable if not more, for some signals than their raw numeric values. How long will it take for NI to put in this basic functionality that has been around on every other system for decades. Its infuriating.

---

Yes this information is pretty important.  Users of my software don't care that the status is 0x0A.  They do care if the status is "Faulted".  That being said it is clear NI doesn't prioritize string representations.  Not only can you not write enum values to the XNet database, you can't view this information in the XNet Database Viewer.  This includes the new fancy preview viewer.