What is the meaning of the task overrun detected output?

7 visualizaciones (últimos 30 días)
Tyler
Tyler el 26 de Oct. de 2017
Comentada: Walter Roberson el 3 de Nov. de 2017
After code-generating my Simulink model to a deployed executable and running it on in a Linux environment, I receive the following messages printed out over stdout:
"Overrun detected: The sample time for the rate 0 is too short."
My model is a multi-rate model and each rate group is as follows:
  • Discrete 1: 0.0005 (2 kHz)
  • Discrete 2: 0.004 (250 Hz)
  • Discrete 3: 0.032 (~31 Hz)
  • Discrete 4: 0.128
  • Discrete 5: 0.512
  • Discrete 6: 3.072
My question is two-fold:
  1. Does "rate 0" (from the error message) refer to the base rate of the model?
  2. Why can't this output be more specific and tell me what part of the model is executing when the overrun occurs?
My question is not about how to fix task overruns (just the above), so please refrain from linking me to posts/articles that tell me to increase my sample time, etc.
Thanks, Tyler
  4 comentarios
Walter Roberson
Walter Roberson el 3 de Nov. de 2017
I am not clear about whether you are getting the message at code generation time, or at the time you run the model?
Are you generating to Arduino, or to Simulink Real-Time with PIL or SIL ?
Tyler
Tyler el 3 de Nov. de 2017
Editada: Tyler el 3 de Nov. de 2017
This is after code generation to a Linux target on a Raspberry Pi - when running the executable .elf file.

Iniciar sesión para comentar.

Respuesta aceptada

Walter Roberson
Walter Roberson el 3 de Nov. de 2017
Editada: Walter Roberson el 3 de Nov. de 2017
Overruns do not necessarily correspond to a particular rate group. Overruns happen when the combination of all of the functions to be executed at a particular time takes longer than the time until the next step. Your minimum step is 0.0005, so at some point the combination of tasks is taking more than 0.0005 s.
t = [0.0005, 0.004, 0.032, 0.12, 0.512, 3.072];
t./min(t)
ans = 1 8 64 240 1024 6144
so the clock will fire every 0.0005 s, and each time it will run everything in the first group; every 8 ticks it will also run everything in the second group; every 64 ticks it will run everything in the first group together with everything in the second group together with everything in the third group (the counts for those all factor 64); every 240 ticks it would run the first group together with the second group together with the fourth group (all factor into 240), and so on. At
fold(@lcm, t./min(t))
ans = 30720
every 30720 ticks it would need to run all 8 groups and finish that before tick 30721, 0.0005 seconds later.
The question is not whether there is one group that runs too slow: the question is whether there is a combination of groups that cannot finish before the next tick... and since all of the blocks will eventually run in a single tick, at lcm() of their times, the question becomes whether all of the blocks together can finish in a single tick.
Certainly if you have a single group that is much more complex than the others then you should address it first, but everything counts.
You can sometimes postpone the effect of running multiple groups by carefully arranging the timings to be relatively prime. For example if the second group ran at every 9 ticks instead of every 8, then instead of groups 1, 2, and 3 all executing every 64 ticks, it would be postponed to every 576 ticks. But no matter what you do, if the simulation runs long enough, the lcm() of all of the timings will arrive and require that all of the groups run in a single tick.
  2 comentarios
Tyler
Tyler el 3 de Nov. de 2017
It would be nice if the output would tell you a summarized version of what successfully ran during a particular tick and what did not (with the leftover work being what causes the overrun).
Walter Roberson
Walter Roberson el 3 de Nov. de 2017
Yup, it would be nice.
My analysis about lcm() did not take into account any kind of delay blocks; for example just because you run something every 64 ticks does not need to require that something running every 8 ticks will align, if the 64 tick version is started 1 tick late relative to the 8 tick version then it will persist 1 tick late.

Iniciar sesión para comentar.

Más respuestas (1)

Fangjun Jiang
Fangjun Jiang el 3 de Nov. de 2017
In your Simulink model, go to menu Display->Sample Time->All. A legend of various sample times will be shown. Hopefully, you can find the one in question.
  2 comentarios
Tyler
Tyler el 3 de Nov. de 2017
That legend is where I pulled the sample times in my question from. Doesn't match up with the error message's output.
Fangjun Jiang
Fangjun Jiang el 3 de Nov. de 2017
Okay. I think the "0" here in "rate 0" might be an ID, not the actual value. You have six rates here so it will be "rate 0" to "rate 5". "rate 0" refers to the fastest rate. Otherwise, it does not make sense. If the rate is 1k, then the sample time is 1ms. If the rate is 0, then the sample time is inf. That won't cause overrun.

Iniciar sesión para comentar.

Categorías

Más información sobre Deployment, Integration, and Supported Hardware en Help Center y File Exchange.

Etiquetas

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by