Data Acquisition Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos
azuther301

More discussion on Hooovah's XNET CRC & Counter code capabilities

Status: New

This is a continuation of another forum post, from here.

 

Hooovah, the capability I need is very similar to how the "ID CRC" feature currently works, I just need a little bit more flexibility in how the ID is added to the payload bytes, prior to CRC calculation.  As you described it, the 4-byte CAN ID is concatenated to the front of the CAN payload, and by your example, it is being added in "big endian" fashion.  What I require for my application, is to add that same 4-byte CAN ID to CAN payload, but I need it added in "little endian" format, such that:

 

if CAN ID = 0x1FFF313

and CAN payload = 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x[CRC]

 

then the CRC is calculated on:

0x13 0xF3 0xFF 0x01 0x01 0x02 0x03 0x04 0x05 0x06 0x07

2 Comments
Hooovahh
Proven Zealot

Okay this wasn't quite what I meant but it's okay. Turns out there was a bug in my software. It was using all 32 bits of the ID, not just the 29. Normally this would be fine, but it turns out those upper 3 bits are used for flags of different kinds and caused issues.  Download version 4 from here:  And try it out. I think the calculations are done correctly now.  If you use the 4 Byte LSB then the calculation is on 0x13 0xF3 0xFF 0x01 0x01 0x02 0x03 0x04 0x05 0x06 0x07 which is 0x5D again using the standard SAE J1850.

azuther301
Member

Great, it's working now, thank you so much for your prompt attention.

 

On a side note, we previously discussed whether this could be used with Signal-Output type sessions.  I now have it working with Signal sessions.  All that was necessary is to make your "Configure CRC and Counter.vi" to be a polymorphic subVI with 2 instances - one with a Frame input and one with a Signal input (as shown below, with the Signal instance selected). The property node inside that subVI can handle both signals and frames, despite the property node items being named "Frm.Active".  The context help for that property node explains that if an XNET signal is passed in, then the parent frame's properties will be modified.

 

azuther301_0-1732208933792.png