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

[aronantonio]

I agree with Manudelavega. I need this function in my application and I'm using NI-XNET API...

[Mario_Z80]

I totally aggree. Since there are messages running in different repetition speeds on the bus, the handling is even more complex and Windows depending.The XNET HW has it's own controller and could completely exclude PC from this task.

I like to suggest a command to configure a message counter with parameters:

- frame name

- counter start position [bit]

- counter length [bit] (typical length is 1 nibble or 1 byte)

- tbd if needed: counter min value (if different from 0)

- tbd if needed: counter max value (if different from bit length)

Alternatively assigning a signal as a counter is ok, but I already saw a data base without defined counter signal and external defined content for using a counter within a frame)

[DG76]

I agree with all the above. Additionally the NI XNET Database Editor could be improved with further functionalities supporting configurable cyclic frames, as well as the hardware such as using the Bus Monitor on its own, which already has the capability to generate frames but in such a limited way as to be pretty much useless (unless to just test a connection), at least as far as my application is concerned.

[JGruenberg]

I'd say they need the ability to do a callback to generate the message data.  I have multiple projects where there is a rolling counter and a CRC embedded into the message, one of these, the OEM has a different hash function for each message (and it includes the counter).

[Hooovahh]

Kudo'd this.  I'm also working with automotive OEMs that require an incrementing counter, and CRC, and not sending this causes devices to set fault errors.  The only possible method of doing this with XNet today, is to write the values frame by frame using the Frame Output Queued Mode, with a buffer of frames which need to go out one at a time which can have the incrementing value, and CRC pre calculated each time.

[Hooovahh]

This feature can be implemented on XNet hardware using an undocumented feature.  I was told unofficially I could talk about this feature, if I don't go into too many details, and I password protect the part of the block diagram that does the magic.  I've made a blog post on this feature here.  And include a download to the zip which should work on any XNet hardware with a program running in Windows or RT.  If you use this and fine it useful, be sure and give that feedback to NI and comment here so that this might one day be an officially supported feature.

If you don't like using unofficial features I do have a way to accomplish this using the Frame Output Queued Mode I mentioned earlier and is detailed in another blog post here.

[GrayJoker]

I have seen the VIs provided by Hooovahh, and then I can transmit frames with rolling counter and CRC checksum. However, the CRC byte I have to send is calculated by No.1-No.7 bytes other than No.0-No.6. I don't know how to modify the codes to make it.

[Hooovahh]

That is an interesting request, I've never seen the CRC be anywhere other than the last byte.  I have seen it be in the 7th byte, or 8th byte, but it was always when the payload was 7 or 8 bytes.  You can accomplish a similar result with the bucket filling technique.  Otherwise it is possible to edit the VI to have that ability but doing support in this idea exchange isn't what this is for.

[GrayJoker]

 The CRC byte I have to calculate is the first byte of a 8-byte frame, which is unusual. I think it is very easy for Hooovahh to modify the VIs to make them more general since we cannot open them because of the password. However, the bucket filling technique is also genius.

[Pog2k]

I also can't understand why NI does not open the "undocumented feature", which is mentioned by hoovah. Actually it is awesome to run code on the xnet device itself ! . Even if it can't be programmed in LV, devlopers should be able to get the most out of the hardware. Don't get me wrong, LV is awesome but i like the mix of programming languages to find the best solution for a specific task.

The Bitbucket "trick" works only if you are delaying the send out signals or you can predict which signals will be generated ?!

I also faced the Problem in Veristand. Out of the box it is possible to use some standard CRC and RC but it is not possible easily add some custom code which is mostly provided by the OEMs in C/C++.