Chen Li

On 9/21/2019 at 2:24 AM, Rolf Kalbermatter said:

Unfortunately it does not show the definition of canfd_frame datatype which seems to be the one that is important here. But there is a chance that this is the actual problem. I would expect the 8 bytes in the cluster in your datatype to be the actual CAN data. In that case your cluster is missing the    

UINT64    timestamp;//us

element and if you pass in a big number of frames as lengh parameter this of course will amount to 8 bytes in the message buffer missing for every message element and that on a total message length that is normally 24 byte! That adds up very quickly and will even cause for small number of messages a problem rather sooner than later.

 

 

Also your CHANNEL_HANDLE and DEVICE_HANDLE are both a pointer so it would be more correct to declare them as Pointer Sized Integer and use a 64 bit Integer on the LabVIEW diagram for it. The way you do it know it will work in LabVIEW 32-bit but it will badly fail if you ever want to move to 64-bit LabVIEW and even if you say now that that won't happen because there is no 64-bit library available either, the day will come where your library provider will give you a library and after you complain that it doesn't load in your software, just will comment: "Who the hell is still using 32-bit software?"

Thank you very much,Rolf.

The error that is caused by  UNIT64 timestamp, and the program is running properly now. This is my fault. 

The program obtains the number of messages in the hardware buffer through ZCAN_GetReceiveNum function, and then calls ZCAN Receive to complete the received data. When the amount of data reaches 1000 frames / s, the program will crash.

UINT ZCAN_Receive(CHANNEL_HANDLE channel_handle,  ZCAN_Receive_Data* pReceive,  UINT len,  INT wait_time = -1);

I think there is something wrong with creating the parameter array ZCAN Receive Data* pReceive. Has anyone ever encountered a similar problem?

Receive.zip