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

9 Comments
Member

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

Member

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)

Member GBN
Member

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.

Member

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 communication? Checkout my 12 part CAN Blog series.

Proven Zealot

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.


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

Member

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.

Capture.PNG

Proven Zealot

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.


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

Member

 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.