Data Acquisition Idea Exchange

About Data Acquisition Idea Exchange

Have an idea for new DAQ hardware or DAQ software features?

  1. Browse by label or search in the Data Acquisition Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see implemented!
Top Kudoed Authors
User Kudos Count
Showing results for 
Search instead for 
Did you mean: 

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

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


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


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)


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.


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

Proven Zealot

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.

Unofficial Forum Rules and Guidelines - Hooovahh - LabVIEW Overlord
Interesting in learning all you can about automotive CAN bus communicatin? Checkout my 9 part CAN Blog series.