Reading 16 byte CAN information with PCI-8512

[kj2shin]

Hello,

I am currently trying to read the sensor data through CAN interface with PCI-8512 and NI RT Computer. This sensor returns total of 16 bytes of data at the sampling rate. Since, CAN only supports up to 8 bytes per frame, I am using sequential frames to read one 8 bytes of payload and another one in a sequence. (so I can get the entire 16 bytes of data). However, this implementation sometimes results problem when the first frame picks up the last 8 bytes of the data at the beginning. This results all the data to shift by 8 bytes.

Is there a better way to implement the labview program to avoid this situtaion?

Thanks for the help in advance.

[nathand]

Normally I would expect that the sensor would send a different CAN ID for the two different sets of data. Are you looking at the CAN ID, or just the packet contents? Do you have any control over the data the sensor sends, or at least a description of the full protocol it uses? If it sends different data with the same ID, perhaps there's another approach, for example a CAN message you can send to the sensor first to force it to synchronize in some way.

[kj2shin]

Thanks for your answer. For the clarification, the entire data is consisted of 16 bytes and according to the data sheet, the sensor is outputing these 16 bytes with the same ID. Hence, I need to read these 16 bytes at once. But from my understanding CAN can only read up to 8 bytes per frame so the problem arises from here. Also, the sensor is constatnly outputting a series of the data at a fixed sampling rate so I do not need to write to sensor to trigger the data acauisition. 

[nathand]

Can you provide a link to information about the way the sensor sends data? Either the sensor protocol was poorly designed, or you're missing some piece of information. If the sensor really operates the way you describe then there's nothing you can do about it. CAN packets are limited to 8 bytes of data so the sensor should provide some way to indicate which set of channels are being sent.

[kj2shin]

Here is the detail about the information bytes:

Thanks.

[GerdW · Accepted solution]

Hi kj,

- if the header is always the same you can use it to analyze your received data packets and to put the received bytes into correct places…

- you can use the checksum to check the correct order of the bytes in those messages…

- if your status is giving you some "expected" values (like OK=00h) you can use this to put your bytes into correct order…

There is so much you can do to verify/assure the correct order of the received data bytes - why do you still have problems with?

[nathand]

Can you provide any information about how that's translated into CAN packets? It's literally just split between the 8th and 9th bytes, then sent as two packets with the same CAN ID? That seems like an unusual scheme.

However, since it appears that your header is constant, you can simply check if the first 4 bytes match the header, as GerdW suggests.

[GerdW]

To add one more idea:

If you're only interested in Fx, Fy, Fz you can throw away all messages starting with this static header (as you only need the 2nd part of that splitted payload data then)…