CAN Frame Signal Conversion With XNet

Question

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 
Unofficial Forum Rules and Guidelines - Hooovahh - LabVIEW Overlord
If 10 out of 10 experts in any field say something is bad, you should probably take their opinion seriously.

Answer 1

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.
Munna