In your case, I recommend using Simulink.BlockDiagram.copyContentsToSubSystem to copy the content of your referenced model into a new subsystem.

http://www.mathworks.com/help/releases/R2011a/toolbox/simulink/slref/simulink.blockdiagram.copycontentstosubsystem.html

You can then replace the Model Reference block by this subsystem using replace_block

http://www.mathworks.com/help/releases/R2011a/toolbox/simulink/slref/replace_block.html

If you send me a simplified example that demonstrates what you describe, I would be interested to give it a look and try to explain or find a workaround for this behavior.

Is there supposed to be subtle differences between ‘Minimize algebraic loop occurrences’ for atomic systems and model references. I have created a simple model which exhibits different behavior between the two (in both 2007b and 2009b). I am ultimately trying to determine if I can help Simulink resolve the generic algebraic loop case with model references for those systems which don’t actually have loops. This is for users who have little experience with the subtleties of model references.

My model is a simple loop of subsystems of a control system. The plant has no direct pass-through paths. Here are the two behaviors:

Atomic subsystems: Highlights the loop at update diagram time and does not allow simulation since update diagram fails. Setting ‘MALO’ on the block which is not direct pass-through caused the block order to change to make this block first and the algebraic loop is no longer detected. Viola. Changing the block order through ‘Priority’ also succeeds in clearing up the false loop detection.

Model references: Throws warnings about the false algebraic loop, but allows update diagram to complete. Simulation is possible, but the algebraic loop algorithm is occurring at each time step, slowing the simulation and causing additional IC headaches. Setting ‘MALO’ in the model which is not direct pass-through does nothing except throw additional ‘Unable to remove algebraic loops’ warnings. Block order remains unchanged and ‘Priority’ is also unable to change Simulink’s mind.

I can send you my example if you are interested.

I just mean that unpacking goes slowly with log.unpack(‘all’) when signals logged out are in deep models. e.g., 6 or more layer. If sinals logged out are in shallow models, e.g. 2 layer or 1 layer, unpacking may be fast.
I wonder if you understand exactly my question.

Thanks

Thanks for the reply.
I have try log out signals in referenced models. Signals can be logged out, but the unpacking is so slow when the signals logged out are in deep models. e.g., 6 or more layer.
Can you give me some suggestions on making unpacking faster.

Thanks and happy new year:)

@Paul – there haven’t been any changes to model arguments as of R2008b, but we are currently working on allowing structures to be passed as model arguments.

@Kevin L – One thing you can do to make changing the SimulationMode easier is to script it. set_param accepts a cell array of blocks, and find_mdlrefs and find_system will return a cell array of blocks. For example, to change the SimulationMode of all the Model blocks contained in a model and all of its referenced models, you could use something like,

>> [refMdls, mdlBlks] = find_mdlrefs(model);
>> set_param(mdlBlks, ‘SimulationMode’,'Normal’);

One caveat is that find_mdlrefs doesn’t load all the referenced models, so you may have to load those models before doing a set_param.

@Kevin L – signals can be logged in referenced models by right-clicking on the Model block and selecting “Log Referenced Signals”. Let me know if you need any more information on this feature.

@Kevin L – we currently don’t support the Simulink debugger in referenced models, but this is a feature we’re working on for a future release.

Thanks for the comments and questions so far, please keep them coming.