Hi all,
We have successfully developped a fair size application on X90CP72 mobile platform which has been running in the wild for 4 years now.
As we add more and more features to our solution, we keep loading the CAN bus that uses exclusively freestyle customs protocols and for which we have to code/decode CAN frames.
We use ArCanReceive and ArCanSend extensively with CAN Id masking when a bunch of CAN IDs are contiguous, or with one dedicated FB for each CAN ID can’t be easily filtered and masked.
As we increase the number of CAN devices, we reach high CPU loads, which seems related to the increasing async ArCAN FB calls according to the profiler.
I start to consider rewriting the CAN receive / routing layer with a bounded WHILE loop and a big switch case to route to each decoding block, in order to minimize the number of ArCANReceive FB instances.
This is not ideal and not desirable to keep the code modular.
I wonder if there are any feed back or best practices about how to best use ArCAN that I could base my design on.
Thanks you for any feed back,
Best regards.
Hi, please try to use the Can ID mask (input parameter of ArCanReceive) in order to use less FB instances for receiving the Can frames.
In general, these Can FBs are executed in the idle time.
In case the CPU load is too high some CAN frames might be lost but the cyclic execution of the system stays available.
Thanks Christoph.
We user CAN ID mask extensively, but have now rewritten the CAN receive layer with dispatch functions to minimise ArCanReceive to the bare minimum. This is closer to what we do on embedded systems (callbacks)
It has improved the overall CPU load a bit.
I regret we don’t get better hindsight into how the runtime works in order to maximise our use of the platform. We have coded a handfull of embedded system way less powered ( 80MHz STM32 with 16kB of memory) that outperform a X90CP72 by 2 orders of magnitude (bandwidth-wise) and we are pretty clueless of how to better approach development.
AS provides many point of control (cyclic timings, X2X config, IO cyclic assignement, …) but no clear guideline at what impacts what and I’ve found investigating the profiler data quite hard.
Has anyone ever done a classification of the most impactfull changes on an application : cyclics timing tuning, asynchronous FB reduction, Modbus r/w size and frequency, IO mapping efficiency tips&tricks, … ?
We have already gotten rid of most string operations.
Thanks for any hindsight.
Hello!
To deal with your issue the first step would be to run the profiler (open → profiler) in automation studio. This will give you a detailed description of execution times, idle times, etc. Once you have that information you know where to optimize. This will also get you a good understanding of the runtime, something you expressed wanting to have.
Like Christoph said the asynch CAN fb calls are done in the idle time. You can experiment with what task class you allocate idle time and how much you allocate (physical view → right click CPU → resources). If you have not considered this you can often optimize while still reaching your requirements.
Hi Carl,
Thanks for your feed back.
We use the profiler a lot, but have quite a large application (for this domain) with third party libraries.
I find quite hard to navigate but this is how we found that ArCandReceive calls where eating all the CPU and changed the architecture.
What I am talking about is general practice : for example
- best approach to use busy CAN bus : reduce receive FB with larger CAN ID mask or not, reuse a send FB or not, …
- best approach to design a Modbus TCP communication : use multiple slaves or use a longer channel list and less slaves, what are the real trade off ?
- do B&R provide functions use any kind of CPU optimisation or is it ok to bring our own primitives (for example filtering, control)
- is it better to design with more POU or is it better to reduce number of POU and use FB inside a bigger one ?
Thanks for your help
Alain