Using Masks inside referenced models

The doc page here:

http://www.mathworks.com/help/releases/R2012a/toolbox/simulink/ug/bqonbts-1.html

says: "To use a masked subsystem in a referenced model that uses model arguments, do not create in the mask workspace a variable that derives its value from a mask parameter. Instead, use blocks under the masked subsystem to perform the calculations for the mask workspace variable."

I think I recently learned the hard way about this, but I believe the wording above is incorrect. It seems to me that if the mask workspace variable derives its value from a mask parameter that is in turn derived from the base workspace, all is well (at least in Normal mode). The problem arises when the mask variable derives its value from a mask parameter that itself derives from a model argument. In this case, it appears that the mask variable will be defined by the value of the mask parameter based on value of the model argument in the referenced model workspace, and not the value of the argument passed in through the model argument list in the Model block.

Though this is a (apparently not quite correctly) documented limitation, it is pretty severe. I can think of all sorts of cases where I would want to have mask initialization define mask variables based on mask parameters set by model arguments. Furthermore, the recommendation to "use blocks under the masked subsystem" might not always be easy (or even possible?). Example: Masked subsystem contains a Sine Wave source block and the frequency of the sine wave is to be computed based on user input via model argument and then through a mask parameter. This should be easy to do, but it's not. Even if it were, I would have to know when I developed the masked subsystem that it will ultimately be used in a reference and take a different approach to developing it, which seems counter to the overall intent of model referencing.

Am I fully understanding this or am I misintepreting the intent and meaning of the documentation?

Answer 1

[Kaustubha Govind]

1. I think that the wording of that statement does imply what you stated: "The problem arises when the mask variable derives its value from a mask parameter that itself derives from a model argument." - I agree that this is disputable, but I think the statement assumes that if you are using model arguments, then all your parameters resolve to model arguments and not to a base workspace variable. However, it could be phrased better to prevent ambiguity. (Please consider submitting an enhancement request to MathWorks Tech Support so the documentation can be improved).
2. I think you might be misunderstanding the statement - the Sine Wave block under your Masked subsystem can still use the mask variable as one its parameters. What it can't use is intermediate variables that are created using the Mask Initialization code in the mask workspace. I think the suggestion is that, if your Sine Wave parameter is 2*k (k is a mask parameter), then instead of creating a variable called p in the Mask Initialzation (p=2*k), just enter 2*k in the Sine Wave dialog box.

[Paul]

1. Why would there be an assumption that all parameters resolve to model arguments? Is that common practice?

2. For the 2*k example your suggestion works. But surely there are cases where we want to do more complex manipulations in masked subsystem initialization based on model arguments. Even if these manipulations could be wrapped up in a function call, it appears that the problems arise when using a function call in the Sine Wave dialog when the input to the function call is a mask parameter derived from a model argument.

[Kaustubha Govind]

1. I'm not sure how common the use of model arguments is, but I was saying that in the context of that text, I think the assumption was made by the technical writer. But I agree that the documentation should be fixed to be more clear.
2. Ah! Having issues with using function calls on underlying blocks is certainly a problem. I'm not sure what to suggest here, because I'm not very familiar with this infrastructure. Would you please report this to Tech Support, so they can contact the appropriate development team please?