NI-XNET: Auto-increment counter byte in cyclic message

[Manudelavega]

Many CAN protocols require a byte in a cyclic message to be incremented each time the message is sent (this is often byte 0). I might have read somewhere that this is possible with VeriStand but I am not using it. So when using only LabVIEW and the NI-XNET API, the only way to achieve this is to call the XNET Write function to manually set the value of this byte. But having to call the API each time the message should be sent removes all the benefits of cylic messages... Moreover LabVIEW can't guarantee the same level of speed and determinism (if the message is to be sent every 5ms for example).

Being able to configure a signal to be an auto-incremented counter would be a huge improvement. To me, this is a must-have, not a nice-to-have...

[jungledede]

I,

First, thanks you a lot Hooovahh, this is alsmost what i need.

I'm working in OEM car manufacture and i have to deal with CRC and roling counter now in the CAN messages.
Like said Pog2k, i get custome sources code in C/C++ like (mostly from Vector CANALYZER). And by custom code i mean that now each frame have it's own way to compute the CRC. 

Also in my team we use Labwindows/CVI, and we can't (yet?) use labview code in our app.

Do you have a ways to have the possibility to send come algorythm to Xnet Hardware from CVI application and for CRC to have more parameters? (like the parameter you add for roling counter, like position, siez..) and more custom CRC than just the XOR and polynomial.

I NI can get official this API it will be very great for a lot of people 😄

[Hooovahh]

First keep in mind that there are two methods of accomplishing the custom frame values.  The more complicated, but fully supported method is the bucket filling technique mentioned in this CAN blog Part 9.  The example code is in LabVIEW but I believe the function calls in CVI is comparable.

The CRC and Counter mechanism I showed is using custom code.  It is basic C code compiled for the XNet hardware.  This custom code is then triggered from LabVIEW.  The example I show in Part 10 is using some code that is already compiled for CRC and Counting.  In theory you could make your own C code, that does whatever custom stuff you want.  Even if you did create your own code, and compile it, and figure out how to trigger it from LabVIEW, doing this from CVI is something I have no experience with.  But it does involve hidden properties of interface and frame sessions.  If the code I provided doesn't work for you I suggest voting for this idea, and then resorting to the bucket filling queued method until something official is released.

[azuther301]

Great work Hooovah; how in the world did you stumble upon this!?  I just tried out your examples from Part 10 and Part 17 of your blog, and they're working great, thank you.

I'm wondering, though, is it possible to alter the C code such that Signal Output Sessions can be used?  If not, I certainly can work with the Frame Session mode, but I generally prefer Signal mode sessions.

The issue is the "Frame" input to "Configure CRC and Counter.vi".  I tried converting your example to use a Signal Output Single-Point session, but that "Frame" input is a problem.  Even if all my session signals are from one frame, and if I pass that frame (as an XNET Frame constant) into the "Frame" input, Labview still returns an error, likely because it doesn't recognize that frame as "Active" in the property node's "Frm.Active" input, since the session is not a Frame-type session.

[Hooovahh]

@azuther301

Thanks for your kind words. The current configuration cannot work on the Signal session type.  But an abstraction layer can be written to help with this.  XNet has a Conversion session type for converting from frames to signals and back.  I even wrote some Frame Signals conversion stuff myself.  With this you can put in the signal values you want, then have that create the frame that needs to go out. I posted some code of that here, and on my blog here.  Internally we have updated this code to allow for writing the CAN signals, then having it do the conversion to the frame, and have it be transparent.  The developer just provides the signals and values to write, and specify what signals are the CRC and Counter, and the conversion does the rest.  That sounds like a fun blog post topic if I ever get to it.

[azuther301]

@Hooovah

On the "Custom Counter and CRC" tab of your most recent "V3" example, do you know how the "ID CRC" options work?  My application does indeed require me to use all 4 bytes of the CAN ID in the CRC calculation, but I haven't been able to create a correct CRC (customer is using this page for CRC calculation verification).  I suspect the issue is either with the sequence in which the (4) CAN ID bytes are added to the payload bytes (CAN ID's LSB first or MSB first) and/or whether the CAN ID bytes are placed "upstream" or "downstream" of the payload bytes, prior to performing the CRC calculation.

But to summarize, do you know details of how the 4 "ID CRC" options work?

[Hooovahh]

@azuther301

You should probably make a new thread just so the Idea Exchange isn't muddied up. But yes I do know the details of the 4 ID CRC option because I wrote it. If used the CAN ID is added to the bytes to be CRC'd before the payload.  So for example a frame with ID 0x04 and 8 byte payload 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x[CRC] will have a CRC of 0xBD using the standard SAE J1850 if you use the 4 Byte MSB. This is because the bytes to be CRC'd will become. 0x00 0x00 0x00 0x40 0x00 0x01 0x02 0x03 0x04 0x05 0x06. I want to make that CRC calculation stuff as useful to as many people as possible so if you need the ID to be after the payload, or something else let me know and I'll try to add it to the configuration.

[azuther301]

New thread started here.