why do Simulink signals end up with different lengths after simulation?

29 views (last 30 days)
Hey guys, I've been working with variable step solvers and I've noticed that some of the signals that I am logging in Simulink end up with different lengths when exporting to workspace (either via To Workspace blocks or logging the signal). I'd assume every signal would be evaluated at every step, ending up with the same length, but that is not what I've been seeing.
Does anyone know why this happens?
It's kind of hard to explain the steps to recreate this, but I am guessing it is not uncommon. Just for a little bit more context, I am running a model that is supposed to simulate a day of operation (86400 seconds). Most signals (33 out of 37) end up with a length of 10939, but a few (4 out of 37) are of length 10801. All of the signals are timeseries and tout follows the length of the majority (10939), as expected. I don't understand why some are exceptions.

Accepted Answer

Walter Roberson
Walter Roberson on 26 May 2023
Generally speaking, conditional execution can result in signals being inactive during all or part of the execution; those are not going to come out the same size.
Generally speaking, there are some sub-sections that have to operate at a higher rate; the signals within those sub-sections would have longer records then the signals that did not have to operate that quickly. We can see this reflected in the detailed structure of Level 1 S files, where the action code for "minor step" is different than the action code for "major step"
Generally speaking, if you are not using inherit of timestep everywhere except perhaps one source block, then the blocks operating at different rates will produce different signal lengths.
Now, speculation time:
If you had an output section that required several steps to produce final output, and did not require all previously-created signals, then hypothetically it would not be necessary to update the previous signals, because they might not be needed. Imagine for example an implementation in which signal values were "pulled": in such a case a signal might not be updated after it was last used.
  5 Comments
Gabriel Ferreira da Silva
Gabriel Ferreira da Silva on 26 May 2023
Thanks again, Walter!
This link helped a lot: https://www.mathworks.com/help/dsp/ug/inspect-sample-and-frame-rates-in-simulink.html (I am yet to check the other ones).
The issue I was seeing was related to a couple of delay blocks that was propagating discrete signals (the ones with shorter length).

Sign in to comment.

More Answers (0)

Products


Release

R2023a

Community Treasure Hunt

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

Start Hunting!