# Guy and Seth on Simulink

## My First Debugging Steps

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.

Signal Dimensions

When dealing with matrices and vectors, I like to enable Port/Signal Displays of Signal Dimensions and Wide Nonscalar Lines

With those options enabled, I can easily identify that the following state-space system has 2 inputs, 3 outputs and 4 states.

Data Types

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

You always want to confirm that your signals are at the rate you expect. For that, turn on the Sample Time Colors and look at the Sample Time 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:

### 4 Responses to “My First Debugging Steps”

1. KMR replied on :

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.

2. Paul J. replied on :

KMR,

Can you expand on your concerns with how Simulink handles sample times?

3. KMR replied on :

(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.

4. Guy Rouleau replied on :

@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:

 Name (required) E-mail (required, will not be published) Website (optional) Spam protection (required): What is 6 + 8 ?

Wrap code fragments inside <pre> tags, like this:

<pre class="code">
a = magic(3);
sum(a)
</pre>


If you have a "<" character in your code, either follow it with a space or replace it with "&lt;" (including the semicolon).

Guy Rouleau and Seth Popinchalk are Application Engineers for MathWorks. They write here about Simulink and other MathWorks tools used in Model-Based Design.

These postings are the author's and don't necessarily represent the opinions of MathWorks.