Real-Time Workshop    

Resolving Conflicts in Configuration of Parameter
and Signal Objects

This section describes how to avoid and resolve certain conflicts that can arise when using parameter and signal objects.

Parameters

Figure 5-9 and Figure 5-10 illustrate a case where both a tunable parameter Kp (declared in the Model Parameter Configuration dialog box) and an identically named parameter object Kp (defined in the Simulink Data Explorer) exist. If Kp is used as a block parameter, there is a potential for ambiguity when Simulink attempts to resolve the symbol Kp.

Figure 5-9: Parameter Kp Defined with SimulinkGlobal Storage Class

Figure 5-10: Parameter Object Kp Defined with Auto Storage Class

An obvious solution would be to assign different names to the parameter and the parameter object.

If this is not desirable, however, you should make sure that the storage class properties of identically named parameters and parameter objects are compatible in accordance with Figure 5-11, Compatible Parameter/Parameter Object Storage Class Configurations. If they are not, an error message will be displayed when the model is run, and/or when code generation is initiated.

In Figure 5-9 and Figure 5-10, the parameter Kp has SimulinkGlobal(auto) storage class and the parameter object Kp has Auto storage class. Accordingly, the symbol Kp would resolve to the parameter object Kp.

Figure 5-11: Compatible Parameter/Parameter Object Storage Class Configurations

Signals and Block States

Figure 5-12 and Figure 5-13 illustrate a case where both a signal Sig (defined in the Signal Properties dialog box) and a signal object Sig (defined in the Simulink Data Explorer) exist. There is a potential for ambiguity when Simulink attempts to resolve the symbol Sig.

Figure 5-12: Signal Sig Defined as SimulinkGlobal (Test Point)

Figure 5-13: Signal Object Sig Defined with Auto Storage Class

An obvious solution would be to assign different names to the signal and the signal object. If this is not desirable, however, you should make sure that the storage class properties of identically named signals and signal objects are compatible in accordance with Figure 5-14, Compatible Signal/Signal Object Configurations. If they are not, an error message will be displayed when model is run, and/or when code generation is initiated.

In Figure 5-12 and Figure 5-13, the signal and signal objects Sig both have SimulinkGlobal storage class. Therefore no conflict would arise, and Sig would resolve to the signal object Sig.

Figure 5-14: Compatible Signal/Signal Object Configurations

Customizing Code for Parameter and Signal Objects

You can further influence the treatment of parameter and signal objects in generated code by using TLC to access fields in object records in model.rtw files. For details on doing this, please see "Object information in the model.rtw file" in the Target Language Compiler Reference Guide.

Using Objects to Export ASAP2 Files

The ASAM-ASAP2 Data Definition Target provides special signal and parameter subclasses that support exporting of signal and parameter object information to ASAP2 data files. For information about the ASAP2 target and its associated classes and TLC files, see Generating ASAP2 Files in the Real-Time Workshop Embedded Coder User's Guide.


  Signal Object Configuration Quick Reference Diagram Block States: Storing and Interfacing