Simulink Desktop Real-Time Kernel error: Maximum supported number of timers exceeded?

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

[Seigan]

Hi Mr. @Jan Houska, I read many of your SLDRT answers. Any advice would be greatly appreciated.

Answer 1

[Jan Houska]

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

Answer 2

[Seigan]

Hi Mr. Houska,

Thank you for your reactivity. I tried the 4 methods and here is my feedback.

• Regarding the CAN(_FD)_MESSAGE_BUS data types:

I’m already using them. My Packet Output blocks are fed by CAN FD Pack blocks (from the Vehicle Network toolbox), for example:

(I call my blocks "CAN FD Transmit" for readability but they're not the CAN FD Transmit blocks from the Vehicle Network toolbox, which I know are incompatible with the Simulink Desktop Real-Time compiler).

I don’t understand how to use the Packet Output block options to specify several CAN FD messages. Both “Msg” signals are of type CAN_FD_MESSAGE_BUS, and as buses, I cannot Mux them. I can only concatenate them using the Vector Concatenate block. But then I get a dimension error:

I tried specifying ‘2*CAN_FD_MESSAGE_BUS’ and {‘CAN_FD_MESSAGE_BUS’, ‘CAN_FD_MESSAGE_BUS’}, but the Packet Output block doesn’t allow me (error).

Could you elaborate a bit more on how to send mutliple CAN FD frames with a single Packet Output block ?

• Regarding setting the sample time to 0:

My model runs in fixed-step descrete solver with a fundamental sample time of 1 kHz. But my CAN(FD) reading and writing needs to happen at lower rates (especially the outputs), between 10 and 200 Hz depending on the frames.

If I set the Packet Output sample time at 0, then I observed this frame gets emitted at my model’s fundamental sample time of 1 kHz, which is too fast. So for the Packet Output, this solution does not work for me, I need to set my CAN frames emission frequencies to specific values.

For the Packet Inputs, I might try it to reduce the number of timers consumed, but the outputs alone consume more than 70 timers currently. As I develop my model, I might reach 128 outputs (with my current way of using the Packet Output blocks, which seem to be incorrect, see point 1).

• Regarding the Real-Time Sync block:

I have a single Real-Time Sync block in my model’s top level, used in Connected IO mode. I try to use the same model for both Connected IO and Run in Kernel mode to avoid too many Model Variants. From what I understand, this block has no effect in Run in Kernel mode but is necessary in Connected IO mode, correct?

• Regarding using only Run in Kernel mode:

I would love this solution, but unfortunately there are some things I do in Connected IO mode that I can’t do in Run in Kernel mode. Mainly, I need to tune a lot of parameters during runtime (which is possible to do in Kernel mode but way more cumbersome than in Connected IO mode). In Connected IO mode I also generate several complex dynamic plots during runtime (with MATLAB functions), which do not work in Run in Kernel mode.

I use the Run in Kernel mode when I really need real-time guarantees and the Connected IO mode helps me during debugging.

I would be interested to know more about the other possibilities.

Thank you

Answer 3

[Jan Houska]

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

Answer 4

[Seigan]

Hi Mr. @Jan Houska,

Thank you for your insights and for the example model. I was able to test this solution and it works okay: the For Iterator manages to send multiple CAN(FD) messages through one Packet Output block, at each simulation step. However, this doesn't work for Packet Input blocks.

In my humble opinion, CAN FD Receive and CAN FD Transmit from the Vehicle Network Toolbox are much easier to work with, because they support vectors of CAN IDs. They work fine in "Connected IO" mode but are not supported currently (2024a) by the "Run in Kernel" mode. Any chance they could be supported in a future release ?

NB: this suggestion resonates with this 2023 post from @Wonjin Shin, indicating I might not be the only one interested.

Regards,

Seigan

Answer 5

[Jan Houska]

Hi @Seigan,

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

[Seigan]

Hi Mr. @Jan Houska,

Any tips to use the Packet Input block in a For Iterator Subsystem ?

Answer 6

[Seigan]

Thank you Mr. Houska,

I know in advance the CAN(FD) frame identifiers I'm supposed to receive, this list is known. However, depending on when I stop the model execution, and imperfect CAN transmission delays, I can't know the total number of frames I expect to receive.

I would be interested to know more about a construct (using the For Iterator?) that could be applied to Packet Inputs, please.

Vectorized Packet Input/Outputs would be a great improvement. Could I submit a feature suggestion somewhere? Or would you be so kind to relay it to the dev team?