support for periodic/cyclic messages/frames

The free CAN Software API (Application Programming Interface) for Windows®
User avatar
barry
Posts: 16
Joined: Mon 18. May 2015, 14:17

support for periodic/cyclic messages/frames

Post by barry » Thu 30. Nov 2017, 12:50

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

M.Maidhof
Support
Support
Posts: 1751
Joined: Wed 22. Sep 2010, 14:00

Re: support for periodic/cyclic messages/frames

Post by M.Maidhof » Thu 30. Nov 2017, 14:17

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

User avatar
barry
Posts: 16
Joined: Mon 18. May 2015, 14:17

Re: support for periodic/cyclic messages/frames

Post by barry » Thu 30. Nov 2017, 16:18

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

M.Maidhof
Support
Support
Posts: 1751
Joined: Wed 22. Sep 2010, 14:00

Re: support for periodic/cyclic messages/frames

Post by M.Maidhof » Fri 1. Dec 2017, 09:40

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

User avatar
barry
Posts: 16
Joined: Mon 18. May 2015, 14:17

Re: support for periodic/cyclic messages/frames

Post by barry » Thu 7. Dec 2017, 09:02

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 ?

K.Wagner
Software Development
Software Development
Posts: 1080
Joined: Wed 22. Sep 2010, 13:36

Re: support for periodic/cyclic messages/frames

Post by K.Wagner » Thu 7. Dec 2017, 11:36

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.
Best regards,
Keneth

User avatar
barry
Posts: 16
Joined: Mon 18. May 2015, 14:17

Re: support for periodic/cyclic messages/frames

Post by barry » Thu 7. Dec 2017, 11:52

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 ?

Code: Select all

/// <summary>
        /// PCAN-PCI interface, channel 16
        /// </summary>
        public const TPCANHandle PCAN_PCIBUS16 = 0x410;

K.Wagner
Software Development
Software Development
Posts: 1080
Joined: Wed 22. Sep 2010, 13:36

Re: support for periodic/cyclic messages/frames

Post by K.Wagner » Thu 7. Dec 2017, 12:02

This is a limitation of the fee free API, PCAN-Basic.
Maximum amount of channels
Maximum amount of channels
Channels.PNG (107.82 KiB) Viewed 15637 times
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.
Best regards,
Keneth

User avatar
barry
Posts: 16
Joined: Mon 18. May 2015, 14:17

Re: support for periodic/cyclic messages/frames

Post by barry » Thu 7. Dec 2017, 13:13

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 ?

K.Wagner
Software Development
Software Development
Posts: 1080
Joined: Wed 22. Sep 2010, 13:36

Re: support for periodic/cyclic messages/frames

Post by K.Wagner » Thu 7. Dec 2017, 13:23

Dear barry,

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

Post Reply