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 ....
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.
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().
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 ?
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: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)...
- 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).
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.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.
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;
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.
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 ?