Jump to content

Receive a large traffic data program crash


Recommended Posts

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

jju0WeQJGObiBjsAAAAgEMAAAAXKq62lH7cUqYdo

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

 

Receive.zip

Link to comment

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 by Rolf Kalbermatter
Link to comment
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 by Fred chen
Link to comment

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

Link to comment
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. 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.