LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Reading 16 byte CAN information with PCI-8512

Solved!
Go to solution

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.

0 Kudos
Message 1 of 8
(3,572 Views)

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.

0 Kudos
Message 2 of 8
(3,564 Views)

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. 

0 Kudos
Message 3 of 8
(3,557 Views)

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.

0 Kudos
Message 4 of 8
(3,549 Views)

Here is the detail about the information bytes:

Screen Shot 2016-12-05 at 10.09.54 AM.png

 

Thanks.

0 Kudos
Message 5 of 8
(3,479 Views)
Solution
Accepted by topic author kj2shin

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?

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 6 of 8
(3,474 Views)

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.

Message 7 of 8
(3,462 Views)

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

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 8 of 8
(3,454 Views)