I am using RT Box 1 and would like to push it to a lower CPU step time. Currently, the step time is set as 5 us and the maximum average cycle time and max cycle time (only happen when starting the simulation) are 3.7 us and 4.2 us respectively.
I reduced the step time to 4 us and set the overrun limit to a very high value i.e. 20000 and still encountered overrun in task error. I wonder if there is a way to solve this.
Can you comment on the firmware version you’re using and if you’re using multitasking? In either case there may be background tasks utilizing part of the available cycle. The best approach would be to try and further optimize your model using some of the techniques in the RT Box tutorials such as “From Offline to Real-Time” and “Model Optimization”. You may also benefit from marginally increasing the 4us step size to a value between 4us and 5us.
The firmware and FPGA version is 3.0.1. And I am using multitasking. Yes this 3.7us cycle time was reached after I made simplification.
The current cycle time is 10 us to guarantee the synchronization with my other system. I tried to reduce it to 5 us and unfortunately, it failed. On the other hand, I did see some other people reduce the sampling time by increasing the overrun limit. I didn’t understand why it failed even if I didn’t reach the maximum cycle time. Could you please give me some hints on what should I do to make the most of RT boxes?
Increasing the number of allowable overruns is a good approach when there is one task that overruns during the model startup. This doesn’t seem like the constraint you’re observing in your model.
If I am interpreting your results correctly, with a 5us step size and 4.2 us max execution time, you are still seeing overruns. This may indicate that the lower priority tasks in your model are the cause of the overrun. The reported cycle time only reflects the load of the highest priority default task with the shortest step size. The base task timing is limiting in most models (and the only timing constraint in single-tasking models) but perhaps not in yours. I would consider the execution time and complexity of your lower priority tasks, especially considering that the low priority tasks can execute when the base task is not executing.
If you post your model I can make more specific recommendations.