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.