XNET Cluster to Raw Frame

[Sam_Sharp]

Are there any functions in X-NET that allow you to convert between different types of CAN Frame formats? In particular, I'm looking to try out logging CAN frames in a TDMS file and for that I need to convert my frames to the Raw format (an array of U8s as documented in the LV help).

I was hoping there might be a function that will allow me to convert between CAN Frame clusters and the Raw format, before I go ahead and write my own?

[Hooovahh]

Well not exactly.  I mean any data type in LabVIEW can be turned into a string, or an array of bytes which can then be written.  But then this file won't be the easiest to open and read without some progam to parse it for you.  If you are going with the TDMS route, then you might get away with pulling out each part of the frame, and writing them to separate channels in the file.  Or the cheap and dirty is turn it into a string and write it.  You'll need to know the type to get it back but that shouldn't be a probelm since it is part of the toolkit.

[Sam_Sharp]

Ok, you're right that I could pull apart the CAN frame data and log that as separate channels in the TDMS file, but TDMS actually supports writing of Raw X-NET data directly to a TDMS file providing you supply a few additional properties (there's an example in the example finder). It's detailed in page 4-564 of the X-NET manual. The reason for using this format is that you can use the CAN Log Importer in DIAdem with a .DBC file to convert the raw data to signal/value data in DIAdem.

I was trying to find something to help generate the U8 array (e.g. from an X-NET CAN Frame cluster).

[Hooovahh · Accepted solution]

You deserve a kudo.  I had no idea this functionality existed and it sounds super cool.  It looks like the VI you want is going to be here.  But I"m not quite sure how the convert settings work, probably default will work

<LabVIEW Install Path>\examples\nixnet\NI-XNET Frame Conversion and Logfile.llb\NI-XNET Frame&Log - Convert Frames (CAN to Raw).vi

EDIT: oh and it looks like some special properties might need to be set on the channel as seen in this VI.

<LabVIEW Install Path>\examples\nixnet\NI-XNET Frame Conversion and Logfile.llb\NI-XNET Frame&Log - Configure TDMS Channel for Write.vi

[Sam_Sharp]

I ended up rolling my own as I couldn't find a built-in function to do it (I already have and use CAN frame clusters in my CAN libraries so don't want to change). If you can do the read/write in Raw format though you can just add the properties to your TDMS channel and wire it directly to the TDMS Write.

I've attached the VI I wrote (LV2013) - it's not a complete implementation as it doesn't handle the 'type' information correctly and I use a slightly different cluster in my CAN library.

Opening this TDMS file up with the Bus Log Converter in DIAdem works though, which is what I was looking for!

Edit: Oh, the first function you posted does exactly that! Have a Kudo yourself! It also handles the byte order properly as well.

[Hooovahh]

Thanks for sharing, but was there something missing from the VI I linked to?  It seems it handles a few things that your conversion doesn't, like if the message is an echo, and if the message is extended or not.  If you try to open your data in DIAdem and your database needs an extended frame it won't open your raw properly, since it will always be not extended in the raw format you generate.

[Sam_Sharp]

At first I thought the function you linked to was the Read Frames (Raw)...I hadn't seen a VI for converting between Raw and CAN Frame clusters.

As you said - theirs is a more complete implementation which handles things that I could do without (e.g. CAN frames > 8 bytes).

[Hooovahh]

Well glad we both learned something today.  But where did you see them handling payload being greater than 8 bytes in Raw data?  It looked like each frame takes up 24 bytes.  Not that I use FD yet.

Edit: Never mind I think I see it in the NI-XNET Frame&Log - Get Frame Size.vi

[Sam_Sharp]

Yeah, the Raw protocol format can support payloads of length greater than 8 bytes and it gets split into 8-byte chunks (i.e. the payload data size must be multiples of 8 bytes, even if the payload length is not a multiple of 8 bytes).

[Hooovahh]

Yeah I don't if it's that big of a deal.  For CAN your payload size is going to be 0, 1, 2, 3, 4, 5, 6, 7, 8, 12, 16, 20, 24, 32, 48, or 64 bytes.  Of these 16 possible options, 7 are evenly divisible by 8.  Of the remaining 9 the average number of extra bytes is only 4.  So if you are given a random frame, you are on average going to have 2.5 bytes of extra padding data.  If you get a lot of frames this can add up, but the total amount of storage for a single standard frame is 24 bytes.  So that means if you had 1000 frames you have 2,400 bytes of raw data, but with padding removed on average this could take up 2,150 bytes, meaning the file could be 10% smaller.  Of course most people are not using CAN FD so maybe your savings could be a bit more.

Could it be better?  Sure but I'm betting this is a pretty seldom used feature.  And anecdotally I'd say a very large majority of the CAN frames I've dealt with had 8 bytes of payload anyway.  I've seen other CAN interfaces assume 8 bytes of payload as well.  It just makes the code easier.