Seth sometimes tells me: Grab the low hanging fruit. When debugging Simulink models, this means looking at the information easily available.
Here are the first three things I usually look at when I see unexpected results in a model.
With those options enabled, I can easily identify that the following state-space system has 2 inputs, 3 outputs and 4 states.
In Simulink, you do not need to specify the data type of each signal. In most cases, you specify the data types of a few sources and the Simulink engine propagates it to other blocks. When a model gives unexpected results, it is always a good idea to display the Port Data Types
For example, how could someone explain that Simulink thinks that 5 is equal to 1? Take a look at this model:
Sample Time Colors and Legend
I have seen too many cases like the following model, where the user designs a position controller to run at 4ms, but forgot to set the sample time of the driver block reading the position of the motor:
Now it's your turn
What are the things you usually look at when debugging a model? Leave a comment here.
6 CommentsOldest to Newest
Related to sample time: I continue to contend that Simulink’s model for sample time is inferior to the SystemBuild model for sample time; it is much easier to make these kind of sample time errors with Simulink. This remains one of the three or four areas where the Mathworks stubbornly refuses to learn from what SystemBuild did 15 years ago.
Not saying that I want to go back to SystemBuild, but it is frustrating that there are still these places where Simulink makes it easy to shoot yourself in the foot.
Can you expand on your concerns with how Simulink handles sample times?
(I don’t check this very often, so apologies to the long time between question and response.)
In Simulink, you typically handle sample times by specifying the sample time of an individual block (say, an integrator) and then having the sample time propagate to individual blocks. The problem is that if you mess up the sample time on one block, it can affect lots of blocks, which is what Guy is showing. Simulink’s design makes it relatively easy to shoot yourself in the foot, sample-time-wise.
In the almost-extinct SystemBuild (part of MATRIXx, which was actually the leader in graphical modeling and code generation until about 2001 or so; that’s a whole ‘nother story), timing attributes were specified at the SuperBlock level (a SuperBlock is similar to Simulink’s Subsystem block, except somewhat less virtual). So every non-SuperBlock inside a given SuperBlock would share the same timing attributes. This greater level of structure to timing attributes makes it substantially more difficult to mess up timing in a SystemBuild model.
I don’t know if this architecture was covered by patent or not, but since AFAIK the Mathworks kept the rights to all patents covering MATRIXx/SystemBuild when they were forced to divest themselves of their purchase of that tool (that’s part of the story alluded to above), there should be no legal problem with allowing the SystemBuild-style timing attributes in Simulink. I am assuming that the Mathworks prefers their design; I do not in this case. My preference would be to allow (not enforce) a Model block to act like a SystemBuild-style SuperBlock and specify timing attributes for the entire contents of the Model block (including inheriting them from a higher-level Model block, for the case of nested Model blocks). Maybe I’m unusual, but for all of my use cases, I always design my Model blocks to be single-rate; that’s what is required to integrate my generated code into an existing real-time framework.
@KMR: Thank you for the comment. I apologize for the long delay before replying.
I never used SystemBuild, but what you describe seems close to the behavior of Atomic Subsystems in Simulink.
Atomic Subsystems have a “Sample Time” property, which is by default set to -1. The value of -1 does not impose any constraints on the sample time of the blocks inside the Atomic Subsystem. As you describe, this gives you the possibility to shoot yourself in the foot.
If your application requires strict usage of sample times, you can specify a positive value for the sample time of the Atomic Subsystem. When a positive value is specified, all the blocks inside the Atomic Subsystem will run at this rate. You will receive an error if blocks inside the Atomic Subsystem are configured to run at a different rate.
There are also ways to enforce models to be single-rate.
In the solver section of the model configuration, by default the “Periodic sample time constraint” is set to ‘Unconstrained’ to allow more flexibility. If your model needs to contain only specific rates, you can change it to “specified” and specify the allowed rates. You can find information on this topic here:
Very useful. Would also like to see a blog entry on “First steps in debugging code written by someone else”. If you’re given a model that someone else wrote, it can be hard to figure out what the model is doing. What are some first approaches to getting oriented?
Thanks KE, I receive models created from others every day, so I have good experience with that. I will try come up with a post on this topic soon.
For a starting tip… I usually open the Model Browser and quickly browse through all the subsystems, level by level, looking for subsystems names, annotations or any kind of pattern. This helps me making a big picture in my head. Then I try identifying critical or important signals that I log and observe using a Scope or the Simulation Data Inspector.