CAN Frame Signal Conversion With XNet

[Hooovahh]

When dealing with CAN, most new developer struggle with the Frame and Channel (or Signal) conversion.  Developers are trying to get away with using the cheapest CAN hardware, and as a result are opting to not use XNet hardware but instead use things like the USB 8473, or using non-NI hardware like the ValueCAN by Intrepid, or using Vector hardware, or CAN to serial adapaters.  The problem with all of these is you generally just read and write frames which is the raw form of CAN.  When using these cheap devices you can't ask the CAN bus what the signal Bus_Voltage is, instead you need to perform a frame read, find the frame associated with the signal, then pull out the bits for that signal, then scale the signal based on the signal selected.

All of this is doable but a pain and can be very custom.  That's one reason NI came out with the Frame Channel Conversion Library.  This library converts from Frames to Channels using an industry standard CAN database file.  The problem with this library is it hasn't been updated in 5 years, and has known issues which likely will never be fixed.

NI has since come out with XNet which supports reading and writing signals on XNet hardware.  The XNet drivers also support converting Frames to Signals without needing hardware at all.  This conversion has several limitations, and really only works for getting the latest value for a signal, not all values.  And in addition to that if the signal was never seen, the value will be the defaul value for that signal, not NaN.

So I wrote a wrapper around the XNet conversion library to handle going from signals to frames, or from frames to signals.  Anyone looking to use a DBC file, on hardware that only supports frame API should use this conversion library, or at least use the XNet conversion sessions.

CAN Frame Signal Conversion Using XNet 

[Munna232]

Hello Hooovahh,

Nice work  . It’s very useful.

I’m also converting CAN Raw data to Physical values in my project. Yes, your correct XNET APIs have some limitations. as you mentioned, there is one more limitation I found,

If your Message Data length (Payload) is 4 Bytes (example) and other CAN Frames are having more than 4 Bytes then its throwing Error (Error Code -1074384737).

While converting CAN Frames to signals, we will get different Payloads but, our selected signal message have 4 bytes then XNET will gives an error (at the time of Data Conversion).

As per attached Snap, My Signal is related to IDxBB and I’m sending two different Frames then XNET will not convert.

Hooovahh Wrote:

 .........................................................................................................................................................................................................................................................................................................................................................................................................................................................

NI has since come out with XNet which supports reading and writing signals on XNet hardware.  The XNet drivers also support converting Frames to Signals without needing hardware at all.  This conversion has several limitations, and really only works for getting the latest value for a signal, not all values.  And in addition to that if the signal was never seen, the value will be the default value for that signal, not NaN.

............................................................................................................................................................................................................................................................................................................................................................................................................................................................

When we will send Frame by Frame then we will get all values (not only recent values). XNET will take previous value (if data is not present for Next iteration)

Please check this snippet for all values & NaN Display.

[Hooovahh]

Oh wow I did not know of this limitation.  So just to clairify.  If you have multiple frames in a database.  And not all frames are of the same payload, when the conversion takes place it will try to use each frame.  But when converting a frame of say 4 bytes and you provide 8 an error occurs.  So even if the frame is not associated with the conversion you are performing, it will throw an error.

The easy fix for this is to just set the payload to 8 bytes for all frames when making the session.  I may add this to my version to avoid this issue.

[Munna232]

Yes. Your correct . I did the same in my project.

At first Reading 8Bytes payload ID from the DBC and adding that signal to my session.

After conversion deleting that index values.

[Munna232]

 Dear Hoovahh,

Recently I found one issue about “NaN”.

Usually displaying “NaN” as output before Signal start. But as per attached image,

Let’s take Signal_C & Signal_D are multiplexed type (CAN IDx100) & Signal_E is Multiplexor.

ID: 0x100 is started at 50ms but Signal_C started at 100ms. So, from 50ms-90ms there is no value for “Signal_C” but NI-XNET convert.vi is giving default value (i.e. Zero (0)).

when I’m displaying in CANalyzer, it’s showing “Blank” (up to 90ms for Signal_C).

I think we need to consider about this also. Not only starting point of ID & also Multiplexor value.

Once data came then no need to check . because NI-XNET APIs will take previous value (if session is live).

I hope you understood this issue.

[Hooovahh]

What you are asking doesn't make sense. You are asking for a signal in a frame to have a value of NaN while other signals in that frame have a values. Remember the frame is going to be up to 8 U8 values. You can't have some bits, or bytes be NaN. This is why default values exist, because when you are sending a frame, where a signal doesn't have a value, the 8 U8 bytes need to have values.

Also this is about my XNet conversion using a DBC. I don't believe a DBC supports muxing frames so I'm not sure what this has to do with my library.

[Hooovahh]

Actually wait, is this about reading signals? If so I totally agree and think my library can be fixed to support this, if DBCs support muxing.

[Munna232]

Thanks for your reply.

This is about CAN Frame to Physical value conversion.

DBC will support MUX frames & also XNET will support.

I think one time you posted one issue about the multiplexed signals (MUX Signals to Frames conversion vice versa).

MUX means, same Bytes will be occupied by more than one signal. Depends on Multiplexor, Signal value will be updated.

Let’s take, DLC = 8 Bytes of ID 0x100.

Byte [0]- Byte [2] related to Signal_C & Signal_D.

If Signal_E (Multiplexor) = 0 ------ > Byte [0]- Byte [2] related Signal_D

If Signal_E (Multiplexor) = 1 ------ > Byte [0]- Byte [2] related Signal_C

When Signal_C Data is displaying then how we can Signal_D values (Vice versa)?

At a time we can see one signal (Depends on Multiplexor).

[Hooovahh]

Yup I understand now. Using what I've learned when trying to apply this to LIN data I'm pretty sure I can make this happen without too much trouble. Could you do me a favor and post a DBC that has muxing in it, so I can use it to test with? I want to make sure it imports into XNet properly too.

[Munna232]

 Dear Hoovahh,

I have added two CAN IDs (0x100,0x200) in your sample DBC with Multiplexed CAN Signals.

Please find the attachement for the same.

Let me know if you need anything else.