This is expected behavior. At compile time Real-Time Workshop needs to know the signal properties in order to be able to compile the code properly.
It is not possible to have dynamically sized inputs or outputs for referenced models. When a referenced model is compiled without any knowledge of the model in which it will be used later on, the size and sampling mode for all signals needs to be set explicitly as it cannot be inherited from the referencing model. In the case that the signal size is not set explicitly, it will use a default of a sample based 1x1 signal. So the model will compile succesfully, however its sizes and sampling mode will not match that of the referencing model and therefore lead to an error at runtime.
There are three ways of resolving this problem:
1) Make sure that you set the sizes and sampling modes of all inports and outports correctly in the referenced model so that they are known at compile time. The drawback of this method is that you cannot use a single referenced model for handling signals of different sizes and a change in signal size of the top-level model requires a change in the referenced model. It will, however, allow you to have the normal benefits of a referenced subsystem like speed of execution and incremental code generation.
In order to set the correct sizes for inports, please follow the following steps:
a. In the referenced model, open the inport that is taking a value from the referencing model
b. Go to the 'Signal Attributes' tab
c. Under 'Port dimensions' make sure you set the correct size of the incoming signal (do not leave it at -1 for inherited)
d. Under 'Sampling mode' make sure you select 'Frame based'
2) Make sure to set the sampling mode of all affected inports to be 'Frame based' as described above and let the signal that comes out resolve to a Simulink.Signal object in the workspace that has the correct Dimensions and SamplingMode properties set. In this way, Real-Time Workshop will resolve all signals to Simulink.Signal objects in the workspace and regenerate the code when necessary. The benefits and drawbacks are similar for the above mentioned approach, however, with the additional benefit of easier maintainability of your code by bookkeeping in an initialization .m file.
3) Do not use model referencing at all, but a use subsystem instead. This approach will result in less speed during simulation and not allow for incremental code generation, however it will allow Real-Time Workshop to determine the size of all signals at compile time. So a single subsystem can be reused many times from a library without changing its contents. Besides, this will allow your final system to contain differently sized frame-based signals and still use a single subsystem.
In the attached .zip-file there are several examples of how the above techniques can be applied:
- model_to_implement.mdl - Shows the full model that is to be implemented
- model_with_subsys.mdl - Shows how this can be done with a simple subsystem
- model_with_ref_default.mdl and ref_model_default.mdl - Show how just copying the contents of the subsystem to a new model leads to the error that you are getting
- model_with_ref_inports_set.mdl and ref_model_inports_set.mdl - Show how the first mentioned method is applied
- model_with_ref_simulinksignal.mdl and ref_model_simulinksignal.mdl - Show how the second mentioned method is applied
