PEAK-System Forum

What development package implements periodic/cyclic message/frames functionality ?
Or do you need to handle that youself in threads ?
Are there some examples ?

While sending periodic frames is the can port still accesible for other communication ....

Hi,

you have to handle periodical/cyclic messages by your application (timer/threads). Yes, a periodical message will not disturb the other CAN communication, our driver has a fifo buffer for Rx/Tx.

regards

Michael

Do you have any example of this and do you know the performance when handling multiple periodic messages ?

Hi,

under Windows, you can use a multimediatimer to handle periodic signals. You will also find timer examples in our source code examples for PCANBasic, used for CAN_Read(). You can also use those timer for CAN_Write().

regards

Michael

Dear Michael,

already thx for the response... for a new project we will probably order 5 quad canfd cards...
so we will have 20 can channels at once ... need to use in parralell with cyclicity around 10 frames.

I tried the multimediatimer for one frame on one can channel ... and that seems work ok.
Now the next step is to implement a robust class/dll where we can have functions to add commands, remove commands, stop and start the cyclicity...

Now i'm wondering if we need to implement multiple multimedia timers or have one multimediatimer where we check if we need to send the frame or not based on a counter (multiple of interval)...
I assume if we use 20 x 10 = 200 multimediatimer (20 can channels x 10 frames each) the system will be stressed.
So maybe the one multimediatimer approach is beter.

Do you have any recommandations on this ?

Hello,

barry wrote:Now i'm wondering if we need to implement multiple multimedia timers or have one multimediatimer where we check if we need to send the frame or not based on a counter (multiple of interval)...

the only person who can answer this is you. This depends on how your communication looks like and how your code is (or should be) arranged. My guess would be:

• If you want to have a function in your DLL that is used for sending frames from somewhere in your code, then you should use a kind of Queue, and use one timer to send that data periodically.
• If you need to send fragmented data (several consecutive frames) where the time between frames vary, then you should use one timer for each send procedure (creating/deleting the timer for each procedure).

barry wrote:I assume if we use 20 x 10 = 200 multimediatimer (20 can channels x 10 frames each) the system will be stressed. So maybe the one multimediatimer approach is beter.

Actually, timers are only windows objects that act as "events", which are triggered by the system when a configured interval elapsed, all based in one central (Windows) tick counter. The amount of objects that can be created is very high and current computer systems can handle them too. 200 Timers shouldn't be a problem, but the need of so many timers for one application is normally an indication of bad design.

ok .. thx for the info ..

1 more question ... I noticed the pcanbasic api only enumerates until PCI interface channel 16...
is this a limitation of 16 can channels ?

Or can we enumerate further ?

This is a limitation of the fee free API, PCAN-Basic.
To use up to 64 devices (and to be able to connect several applications to the same channel) you need the PCAN-Developer, which is the professional version of the API. This API is kind of more complex to use than PCAN-Basic.

Dear Kenneth,

Do we need to purchase this API "license" for every setup we want to use .. or can we buy it once and than use it on multiple system.
Could you please also send me an offer/quote for this ?

Dear barry,

please send your request to support[@]peak-system.com refering to this post, and you will get the desired information.