Receive a large traffic data program crash

[Chen Li]

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

[Rolf Kalbermatter]

From the look of it I would guess a bug in your zlgcan_wrap.dll or one of the myriads of other DLLs it depends directly or indirectly. Nothing in the LabVIEW diagram looks suspicious from the little information (none) we got from you about this DLL interface!

So what is the C declaration of this function and its datatypes and subtypes?

Edited September 20, 2019 by Rolf Kalbermatter

[Fred chen]

2 hours ago, Rolf Kalbermatter said:

From the look of it I would guess a bug in your zlgcan_wrap.dll or one of the myriads of other DLLs it depends directly or indirectly. Nothing in the LabVIEW diagram looks suspicious from the little information (none) we got from you about this DLL interface!

So what is the C declaration of this function and its datatypes and subtypes?

Thank you for your reply. The attachment is the header file.  It should be noted that when the acceptance rate is low, the program can run normally.

zlgcan.h

Edited September 20, 2019 by Fred chen

[Rolf Kalbermatter]

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?"

[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.