# New Blocks in Simulink R2010a26

Posted by Seth Popinchalk,

This is the time of year (in the northern hemisphere), where the ice and snow start to recede, the birds return, and the days start getting longer. It signals the arrival of ... a new release of MATLAB and Simulink! MATLAB R2010a is now available for download by licensed users from MathWorks.com.

Instead of reading through the Simulink release notes, check out the Simulink 7.5 Latest Features page. It has most of the same information as the release notes, but it also includes links to a great presentation including highlights and screen shots from the release. There are links to videos that introduce some new features.

New Blocks

The rest of this post is dedicated to introducing you to a few new blocks in R2010a.

The Second Order Integrator block simplifies making accurate models of systems with limits. (Think of a ball hitting the ground: position stops at zero, and velocity immediately goes to zero also.)

These are different versions of the new Square Root Function block to perform square root, signed square root, and reciprocal square root operations.

The Trigonometric Function block can now compute SIN and COS with the CORDIC approximation.

The For Each Subsystem makes it easy to take a scalar algorithm and apply it to a vector signal (or a vector algorithm and apply it to a matrix of signals, etc.). In the generated code, For Each Subsystems that have the same scalar algorithm but different dimension inputs can now share code.

The Function Call Split blocks enable branching of function call lines. Now the same Function Call Initiator can execute multiple subsystems (eg: Function call generator, or Stateflow Chart.) This removes unnecessary rate transition blocks when there are data dependencies between two subsystems executed by the same initiator.

The Multiport Switch block now has labels on each of the ports to identify which values pass through that port. It also works with enumerated types. Now there is also a Find block, based on the popular MATLAB function. It will return the indices or subscripts of the non-zero elements of the vector/matrix signal at its input port. You can also return the values of those non-zero elements.

Read the release notes and tell me what new or enhanced feature of R2010a you are most interested in by leaving a comment here.

GG replied on : 1 of 26

Is it now possible, to use the data-store block (read and write too) with nested buses?
Concerning code generation this would allow to hold block-data inside compact structures for multiple instanced functions, etc.

Regard’s
GG

Kaushik replied on : 2 of 26

GG,

We are working on adding non-virtual bus support to data store memory (along with read and write blocks). However, this will not be available in R2010a. If you have any specific use cases that you would like to share with us on this, please let us know.

Thanks,
Kaushik

XaL replied on : 3 of 26

Hi,

I tried to search within the release notes, but the answer doesn’t seem to be included:
Is the Linux Simulink interface similar to the Windows one on the R2010a release? Does it include a model browser now?
“The current Simulink editors do have some limitations based on the platform you use. Our long term goal is to upgrade the editors so all features will work across all platforms. This is part of a major architectural upgrade that has been on-going for a few years. Thanks for letting us know that this is important to you.”
Is the major architectural upgrade over by now?

Seth replied on : 4 of 26

@XaL – Thank you for your good memory! The major architectural upgrade is still underway and involved many developers full time. Unfortunately, I don’t have a time-line for when this will be available.

wei replied on : 5 of 26

@seth, one feature I like to see is multi-port/datatype support for From/To-workspace block, like scope block.

Checker replied on : 6 of 26

@seth, Is it on your(mathworks) radar to provide the ability to use a stateflow library block inside another stateflow?

@Checker, You can place a Stateflow library chart inside of another Stateflow chart via the Simulink function object (as of R2008b). Would that solution work for your models?

Checker replied on : 8 of 26

@Michael, I am currently using the same methodology you mentioned (Stateflow- Simulink integration). It works, but its not as convenient as using directly a stateflow lib inside another stateflow ( U need to create ports, specifiy thier sizes …).

Paul J. replied on : 9 of 26

I checked out the new features and am a little disappointed that there is nothing new on model arguments for model referencing. Based on my understanding of how model arguments work, I have concerns about how effective the current approach is for models that have lots of nested model references.

Mike Tocci replied on : 10 of 26

@Paul J. – Can you give more details on what problems you think you will run into with model arguments? Also, what enhancements you’d like to see?

Thanks,
Mike

Seth replied on : 11 of 26

@wei – Thanks for the feedback! I have passed your comment along to development.

Paul J. replied on : 12 of 26

Mike,

All of my comments are based on 2009a. My apologies if I’m not up to date.

Suppose I have a widget.mdl with 10 model arguments. Now supose I have 10 references to widget.mdl inside machine.mdl, and machine.mdl also has 10 model arguments that customize it. Now suppose I have a factory.mdl that has 10 refrences to machine.mdl.

So what are (some of) the issues:

By my count 1000 model argument values have to be defined when simulating a factory. This is true even if *none* of them are intended to override the default values defined in the model workspace of the machine and the widget.

The only way for factory.mdl to customize each widget in its machines is for the machine.mdl model arguments to include arguments that only exist to pass through to each widget. So each machine must have 110 model arguments. It may be feasible to simplify that list by capturing the arguments for each widget in 10 seperate arrays, but that only works if the widget.mdl arguments are compatible with each other, since we can’t use cell arrays or structs as model arguments. No matter what, some of these argument lists are going to get very long and unreadable.

Furthermore, the developer of factory.mdl needs to know how to set the argument values for each widget in its machines. In many cases, this higher level developer shouldn’t have to deal with this, unless they want to override what the machine developer did. Seems like this would break down very quickly; imagine how much knowledge is required to develop company.mdl that includes references to factory.mdl.

I have a few other concerns, but this is good for now. Am I off base on any of these? Have there been any changes in 2009b or 2010a that address these? I have a list of enhancements I’d like to see, but many wouldn’t make sense if anything I’ve said above is incorrect.

Mike Tocci replied on : 13 of 26

Hi Paul,

Thanks for the detailed response, it’s really helpful. From what I understand, you have two complaints for model arguments,

1. You can not use structures or cell arrays for a model argument. When the arguments have different types, this means you must pass in each argument separately, which can lead to very long argument lists.

2. Once a referenced model states it has model arguments, the parent model must pass in an override value, even if it really wants to use the default value.

For #1 there is some good news, in R2010a, we now support using structures as model arguments. See the release notes for R2010a here,

Also, see the documentation for structure parameters,

For issue #2, we don’t currently have a way of telling the referenced model to use the default value. The best workaround I can think of is to mask the Model block. In the mask, you could give the option of using the default value, but it would require more bookkeeping in the workspace to keep track of the defaults.

Let me know if this helps, or you need any more information.

Thanks,

Mike

Paul J. replied on : 14 of 26

Mike,

Thanks for pointing me to the doc for #1. I hadn’t checked the release notes for 2010a, only the Latest Features page. I’m surprised I didn’t see it mentioned there, I think it’s very signifigant.

#1 and #2 aren’t my only concerns, but probably the biggest.

Anyway, I’ll eventually upgrade to 2010a and play with the structures, which sounds like a significant upgrade.

Thanks again!!!

Paul

Mike Tocci replied on : 15 of 26

@Paul – You’re right about the R2010a Latest Features page, there’s a short blurb about tunable structure parameters, but it doesn’t mention that this includes model arguments.

You can respond here if you have any other questions or concerns and I’ll try to get back to you.

Thanks,

Mike

Paul J. replied on : 16 of 26

Mike,

With respect to structure parameters I’m confused as to what’s actually new. I’m still back on 2009a, and in this version (and previous ones too) I’ve been able to put numerical data into a struct and then dereference the fields in block parameter expressions. I could also send the entire struct into a masked subsystem dialog and then dereference it inside the subsystem blocks as needed. Have I been using an undocumented feature all this time?

Paul

Paul J. replied on : 17 of 26

Mike,

I’ve been reading the documentation on passing structs as model reference arguments.

it says:
“When you pass a structure parameter to a referenced model, the structure definitions must be identical in the parent model and the submodel …”

it doesn’t explain how to define the structure in the model workspace. Maybe it’ll be obvious once I get my hands on 2010a and can try it, but for now all I can do is read the online documentation ….

Paul

Mike Tocci replied on : 18 of 26

Hi Paul,

1. The key addition is tunability, which in turn allows structure parameters to be model arguments. You’re right that you could do all you say in R2009a, but you couldn’t mark these variables as tunable, which particularly affects Real-Time Workshop code. I noticed that the release note I pointed you to is misleading about this, it should say that tunability is the new feature, I’ll check if this should be updated.

2. The easiest way to add struct variables to the model workspace is to create them in the base workspace and copy them over to the model workspace using the Model Explorer.

Mike

lorri replied on : 19 of 26

how did they create the square root block, especially using simulink??

Paul J. replied on : 20 of 26

Mike,

I’ve started to explore using structures as model reference arguments in 2010a and I’m running into some problems, even though it seems like the process should be very straightforward. The documentation is not very helpful in this area, IMHO. For example, this page

doesn’t even mention the fact that structures can be used as model arguments.

So let me ask very basic questions:

1. Can a structure used as a model argument be a naked Matlab structure variable (just like one can used a scalar Matlab variable) or does it have to be encapsulated in the Value field of a Simulink.Parameter object?

2. Does the answer to 1 depend on the contents of the structure argument, such as whether or not the structure argument contains a field that is itself a structure or structure array?

3. For that matter, can a structure array be used as a parameter (the doc is silent on this question as far as I can tell)? Can a model argument be a structure array or have a field that is a structure array?

Thanks,
Paul

Paul J. replied on : 21 of 26

After some experimentation, it appears that I don’t have to use Simulink.Parameter objects, but it also seems that a model reference argument that is a structure is not allowed to contain a field that is itself a structure array. Is that a constraint on structure parameters in general?

Also, in looking through the documentation I came across the concept of Model Reference Variant. This seemed promising until I saw that a variant Model block can’t contain continuous states. Why is this constraint necessary when it’s not applicable to a non-variant Model block?

Mike Tocci replied on : 22 of 26

Hi Paul,

1. I agree the doc section on Model Arguments needs to be updated to reflect the support for structures. I’ll see if this can be updated for 10b.

2. Your experiment is correct, you do not need a Simulink.Parameter to wrap a structure parameter.

3. Arrays of structures are not allowed in 10a. Structure parameters can be thought of as an analogue of bus signals, and arrays of buses are not currently allowed in Simulink.

4. I think the documentation for Model variants limitations may be incorrect, continuous states are allowed in variant models. They are only not allowed when using the preprocessor conditionals option when generating Real-Time Workshop code. I will double check this and let you know.

Mike

Mike Tocci replied on : 23 of 26

The documentation for Model variants limitations is not correct, there is no restriction on continuous states. This restriction only applies to one specific part of the Model variants feature, using preprocessor conditions in RTW code.

John Dzielski replied on : 24 of 26

I am trying to figure out how to pass a structure as an argument to a model reference block. This post suggests that it’s possible starting with r2010a. The links to the release notes and what seems to be an example in this post are broken. I called tech. support, but after several days haven’t gotten the answer. Can you point me to something that show me how to do this? I am working with r2010a.

Seth replied on : 26 of 26

@MikeT – Thanks for providing the direct link…

@John Dzielski – Happy New Year! I checked into the support case you mentioned, and it looks like we got back to you yesterday. We had a 4 day weekend at MathWorks, so our support team was off. Thanks for your patience and understanding!

What is 2 + 9?

Preview: hide

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