PEAK-System Forum

I'm trying to figure out the best way to read messages from the bus using PCAN-Basic with a PCAN-USB from C#.

My main concern with the 1-thread event model is loosing messages if my thread is busy with one message when another arrives.

Does the driver have an incoming message queue, and how big is it? Does the event fire to read the next message in the queue when there is one, or just when they actually arrive, regardless of where they might be in the buffer? Or is there just the buffers provided by the CAN Controller (the 64-bit receive FIFO)?

One solution is having many threads, the other is to NOT use events and make sure my read loop is fast enough to not let the buffer fill up.

This may be somewhat academic, as I don't know yet how much time my threads will spend on a message, or even how fast the data could be coming in on the bus, but planning for maximum throughput, that's several thousands of messages per second to process ... Of course I plan on simply interpreting and displaying the data ... skipping the odd message here and there might be OK ...

Thoughts?
Thx
J.F.

You know what? there's no way a display updates as fast as that data comes in ... so I'll have to see how many parameters if I need to display per frame, at 20 or 30 frames per second, that should be more manageable.

Still curious as to the answers to those questions regarding buffers/FIFO ...

if you have download the sample applications, you found a C# sample which use a event thread for reading.

The incoming message buffer of the device driver is 65.000 Msg! (real Software Buffer)
So you always read fromn this buffer when you call CAN_Read(). When the driver get a CAN Message from the real CAN Contoller Buffer, it raise the Event, so that your application now that new Messages are placed into the drivers.

The time stamp in the timestamp struct is set when the driver get the Event from the CAN Controller (so this time is for your application always in the past)

Our CAN Hardware and driver could handle up to 8000 real CAN Frames per Second (1MBit Baudrate). Work with the Data is no problem for normal PC´s but show all Data and update Screen etc. is dificult.

Yup I saw the c# example ... uses a single thread though ... we'll see whether that's enough for my needs.

At 30 frames per second, that 33ms, we'll see!

Thanks though, you answered all my questions!

I am using PCAN-BASIC API USB interface. I am developing an application which read/process 6 frames/sec although I am receiving 17 frames/sec from my device. I have red buffer is FIFO. So after1 second when I will read I will get 7th frame ?
Second question from your last comment, is there 2 buffer , one is 'incoming software buffer' with 65,000 messages capacity and other one is 'real CAN Contoller Buffer' with 32,6500 capacity ?

I do not understand your first question - sorry.

The driver is event driven, you could receive up to 8000 Frames per Second on a 1MBit Bus without any problem.
But it´s up to your application what to do, in which time, with the Data!

Always read the queue until it is empty when you get a receive event (loop while PCAN_ERROR_OK, if the quue is empty you will get the PCAN_ERROR_QRCVEMPTY - but also check for "real" Errors!)

The CAN Controller have not the 655536 Msg Buffer - that is not possible - the CAN Controller have, depending on the used one, some bytes...

The Incomming queue and the outgoing queue could each store max. 32768 CAN Frames (not as i wrote 65536 - this is the complete queue size for in and outgoing CAN Frames).
That means if you init your CAN Interface and did not read from the queue, it will run into the PCAN_ERROR_QOVERRUN error after some time (on an 1 MBit Bus with 8000msg/seconds you have 4 Seconds until the queue is full!)