01-17-2017 11:15 AM
Each element of the payload array represents one byte. That's all. You can view that byte in decimal, hex, binary. You might find it helpful to right-click the numeric constant (the blue-bordered payload array element) and show the radix, then click the 'd' for decimal and change it to 'b' for binary.
01-18-2017 02:21 PM
In response to your statement:
Your "CAN MSG Properties" image is on the right track. The only thing unknown here is the placing of the data in the message: you might stuff 2×9 bits like you do in your "message overview" - but I guess using 16bit entries for each accelerometer value is more probable…
After looking this over, it appears to me that using 9 bit entries would be somewhat complex and 16 bit entries would be the better way to go. Do you agree? Thanks!
01-18-2017 02:31 PM
Hi sfrosty,
when I can design my own CAN messages I try to stay at byte boundaries, using bytes or words per signal.
In case I'm limited in "space" (available message IDs) I also use nibbles (4bit entities). When there are single bits (like error flags) I stuff them in one byte.
In your case I would either use 3 words (16bits per signal) or 3× 12bit signals using 48 or 36 bits of the full 64bit frame…
01-18-2017 02:41 PM
Kool!
How's this:
attached
01-18-2017 02:48 PM - edited 01-18-2017 02:54 PM
Hi sfrosty,
now it looks ok - as I suggested using 3× 16bit signals…
Good luck!
Edit: to manage CAN message definitions I can recommend CANdb++ from Vector. This tool is available for free!
01-19-2017 12:56 PM
01-19-2017 01:23 PM
@nathand wrote:
XNET Read returns an array of frames - an array of clusters, where the cluster structure represents a CAN frame, and each frame is one array element. Within the frame cluster, the "payload" element is an array of up to 8 elements. So, when you tell it to read N frames, you get an array of N clusters, and each cluster contains a payload of up to 8 bytes.
Just wanted to thank you again! from sfrosty