Simulink Desktop Real-Time Kernel error: Maximum supported number of timers exceeded?
48 views (last 30 days)
Show older comments
Hi all,
I'm using the Simulink Desktop Real-Time toolbox in MATLAB 2024a Update 6.
I'm on Windows 10 with Hyper-V and High Precision Event Timer enabled.
I'm reading and writing quite a lot (100+) of CAN and CAN-FD frames using the Packet Input and Packet Output blocks.
I'm using both the 'Connected IO' and 'Run in Kernel' modes depending on my needs: 'Connected IO' allows more interactivity whereas 'Run in Kernel' guarantees real-time performance.
I used to use CAN FD Receive and CAN FD Transmit blocks from the Vehicle Network toolbox, which I prefered because they allowed me to receive and send multiple CAN(FD) frames with a single block. But unfortunately they're not compatible with the 'Run in Kernel' mode (see this answer).
My issue is that I have so many Packet Input and Packet Output blocks, that I get this error in 'Connected IO' mode :
Error reported by S-function 'sldrtsync':
Maximum supported number of timers exceeded.
- What is the maximum number of timers allowed?
- Is there a way to increase this number (in the toolbox options maybe?), or is it hard-coded in the real-time kernel?
- What would be the alternatives to send/receive many CAN(FD) frames in 'Connected IO' mode ?
Thank you
Answers (6)
Jan Houska
on 3 Sep 2024
Hi Seigan,
there is a maximum of 128 timers available in the Simulink Desktop Real-Time kernel. This number is fixed in the code and cannot be changed.
However, a model typically requires much smaller number of timers (usually less than 10). There are multiple ways to modify your model so that it does not exceed the number of available timers. You can choose any of the methods below, or a combination, according to your preferences.
- use CAN_MESSAGE_BUS or CAN_FD_MESSAGE_BUS data types as the input signal to the Packet Output block. These data types contain the CAN message ID which overrides the message ID specified in the block parameters. This way, you can use the Packet Output block much like the CAN FD Transmit block and reduce the number of the blocks in the model.
- specify 0 as the sample time for some of the blocks. This will switch the blocks to continuous mode which does not require a timer but processes the data immediately. As long as there is at least one block left with the original sample rate, the model will still be synchronized to real time. Especially the Packet Input blocks can be modified this way.
- eliminate any Real-Time Sync blocks. These are not needed because the Packet Input and Packet Output blocks already perform the synchronization by themselves if they have a discrete sample time set.
- use Run-In-Kernel mode only. In this mode, the model compilation phase coalesces all the blocks with identical sample rates so that they are all served by one common timer.
There are even more possibilities than this - please let me know if none of the above fits your use case.
Good Luck, Jan
0 Comments
Jan Houska
on 5 Sep 2024
Hello Seigan,
just a comment to the Real-Time Sync block: if a Packet Output block (or other similar block) has a positive value of sample time, it synchronizes to real time the same way the Real-Time Sync block would, so if you have both these in your model, the the Real-Time Sync block is not needed. But deleting it would free just one timer which will not solve your situation anyway.
After some more investigations, there is probably no trivial solution to the problem. The Packet Output block indeed does not support bus arrays. I'm attaching a model that attempts to solve this limitation. The bus array is sent to a For Iterator subsystem that contains the Packet Output block and processes the individual CAN FD messages one-by-one. Because the block must have a sample time of -1, there is a zero-order hold before the subsystem that specifies the sample rate for the subsystem. And, because all the blocks have sample time of -1, the Real-Time Sync block is needed this time.
You can try to group your messages by their sample rate, combine them into bus arrays, and use the approach shown in the model for each of the message groups. Please let me know whether it works for you.
Good Luck, Jan
0 Comments
Jan Houska
on 24 Sep 2024 at 13:07
for Packet Input block, the issue is that you don't know the number of received messages in advance. Or do you? If yes, a similar construct may be possible.
Unfortunately, it is not technically feasible to support CAN FD Receive and CAN FD Transmit from the Vehicle Network Toolbox in Run in Kernel mode. However, enhancing the Packet Output block to support vectors on CAN_MESSAGE_BUS (and FD) buses may be possible.
Best Regards, Jan
0 Comments
See Also
Categories
Find more on Development Computer Setup in Help Center and File Exchange
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!