Comments on: Organizing Mask Callbacks

By: Seth

Seth — Tue, 23 Mar 2010 20:22:57 +0000

@Jack – The gain value from your mask will not be in the base workspace. The preferred method to access these variables from the MaskInitialization code is to pass them into the function or just use the value. It is assigned in the mask workspace before the MaskInitialization code runs, so it should be available.

There is an example of this in my post on Mask Initialization.

I recommend against using evalin inside MaskInitialization because it is hard to code for all the different cases handled by hierarchical resolution.

By: Jack

Jack — Mon, 22 Mar 2010 12:32:36 +0000

I organize my mask callbacks like you but when the masked blocks are used in a mask susbsystem, I get an exception when I try to evaluate the subsystem parameter from the masked block. For example my masked block is ‘Timestwo’ with parameter ‘gain’. I put Timestwo in a masked subsytem named ‘Top’ with parameter ‘topgain’. I initialize the parameter ‘gain’ of Top/Timestwo at ‘topgain’. When I use evalin(‘base’,get_param(‘Top/Timestwo’, ‘gain’)), I get an exception which states that the parameter ‘topgain’ is undentified. Is there a way to access to parent parameter from the child ?

Thanks for your help

By: Albert Kröber

Albert Kröber — Mon, 08 Dec 2008 12:12:11 +0000

I’ve asked the Mathworks support. And they said that it is not possible to detect the signal width in the inizialization code of a mask. Also the Probe-block can’t solve the problem.

At the moment the user has to write the signal width by himself in the mask of the block.

Anyway, thank you for your help

By: Seth

Seth — Tue, 25 Nov 2008 14:02:51 +0000

@Albert Kröber – The model function should not be called from the initialization code of a Mask. Mask initialization is called during initialization of the model. This means, at the start of the simulation your block would start to initialize itself, again during the process of init. THEN, the same block would tell the model to terminate. I believe we prevent this from working in the initialization code to prevent a infinite loop.

You can use the get_param commands to gather the CompilePortWidth, but there will be a result of 0 when the model is not compiled. You can check for this 0 in a conditional command and only apply an action when the value is non-zero and your data is valid, otherwise, do nothing.

How are you using this information? The Probe block can return the signal width as a signal line which is used in a downstream calculation. This is often preferred over depending on initialization code to gather this information.

By: Albert Kröber

Albert Kröber — Thu, 20 Nov 2008 15:09:58 +0000

Hi Seth,

Is it possible to detect the width or dimension of an input signal of a masked block in the “Initialization-Code” of the Mask-Editor?

At first I’ve tried to use the paremeter ‘CompiledPortWidth’ of the input port with these 4 commands:

modelname([],[],[],’compile’);
q=get_param(gcb,’PortHandles’);
dim = get_param(q.Inport(1),’CompiledPortWidth’)
modelname([],[],[],’term’);

It doesn’t work in the ‘Initialization-Code’ but in the MATLAB prompt. Do you know where I can add code that is executed while the model is compiled.

My second idea was the block ‘Probe’. This block detects the width/dimension and generates a signal with that value. But I don’t know how to use the value of an input-signal in the ‘Initialization-Code’ of the Mask-Editor.

Have you any idea?

Thanks for your help and all the tutorials.

Albert

By: wei

wei — Tue, 09 Sep 2008 12:09:25 +0000

Hi Seth,
For some build-in blocks (for example, the constant block), there are multiple tabs (“Main” and “Signal Attributes”). The dialog window also uses multi-columns. Further, there is “Data Type Assistant” feature which can be shown/hidden with a button, iconed ‘<>’, click.

How could Simulink modelers add these capabilities for their custom blocks without invoking handle graphics?

By: John Reilly

John Reilly — Tue, 09 Sep 2008 11:37:51 +0000

Seth: Thanks for your reply. I have constant block values that depend upon parameter values. In order to provide user notification as early as possible, I have my mask callback for parameter A calculate the constant C whenever A changes. That way I can generate an error as soon as possible. From a usability perspective, I feel this is the best experience. But it sounds like I should wait until initialization?

While we’re discussing it, does TMW publish a “best practices” document for developing Simulink blocks? That would be helpful. (Your articles on masking contain content that I’d like to see in such a tome.)

Thanks again.
reilly.

By: Seth

Seth — Fri, 05 Sep 2008 03:48:48 +0000

@ John Reily – The string entered into your mask will be evaluated in the parent workspace, (it could come from a system above the current one), or it may trace all the way back to the base workspace.

The Dialog Callback is tricky because you can’t always guarantee that the value is known. For example, when I set a gain value of A, I often later add that to the model workspace, or base workspace. The tricky problem you face is trying to anticipate where the variable is coming from, and as you note, it could be in the model workspace, the MATLAB base workspace, or some parent system workspace that passed down through hierarchical resolution.

An alternative design is to use Mask Initialization to check the value. At that point, the value is known and available to your code without calling get_param.

Can you give more details about what you are trying to do in yor mask callback?

By: John Reilly

John Reilly — Fri, 29 Aug 2008 14:18:07 +0000

Seth:
Thanks for a great series. As I am in the process of building a set of Simulink blocks, these were both timely and helpful.

I took your advice, and the advice of a commenter to create an “enumeration” of parameter indices. Now my callback switchyard calls get_param(blk, ‘MaskNames’) and passes that result to the individual handlers. Using the global enumerated indices, I don’t change any code if I rename parameters. I just have to keep the enumerations up to date.

One question. If my parameter is set to a variable, get_param() in my callbacks returns that variable string. I’ve found that I have to try evaluating the get_param() results in first the model workspace, and then the caller (i.e. MATLAB’s) workspace if I need the actual numeric value. Is this indeed the case? Is their an easier way?

Thanks again.
reilly.