This bug has been fixed in Release 2006b (R2006b). For previous product releases, read below for any possible workarounds:
A DWork vector can contain state information that is particularly useful when you have multiple instances of an S-function in your model. The advantage of using DWork vectors to store state information is that Simulink will allocate memory, assign values, and de-allocate memory. You do not have to interact with pointers, and the DWork vectors become part of the SimStruct structure and can be accessed anywhere in the code.
A DWork vector can be accessed in two ways:
1. Accessed via the identifier assigned to it
/* Exported block states */
real_T mySignal; /* '<Root>/S-Function' */
2. Accessed as a field in the DWork structure.
/* Block states (auto storage) */
D_Work_modelname modelname_DWork;
When the DWork vector identifier is a field in the DWork structure, it may be accessed as follows:
/* states (dwork) */
modelname_DWork.mySignal = 0.0F;
In order to access the DWork vector by its identifier directly, you must set the storage class to "ExportedGlobal" in the workspace or in the S-function. The two ways you can achieve this functionality are:
a. The DWork vector can be named after a signal in the MATLAB workspace. For example, the following code creates a Simulink signal and sets its storage class.
mySignal = Simulink.Signal;
mySignal.RTWInfo.StorageClass='ExportedGlobal'
In your S-function, use the following macros in the callback mdlInitializeSizes
ssSetNumDWork(S, 1);
ssSetDWorkWidth (S, 0, 1);
ssSetDWorkDataType(S, 0, SS_SINGLE);
ssSetDWorkRTWIdentifier(S, 0, "mySignal");
NOTE: The macros are not intended for use outside the callback mdlInitializeSizes.
b. Alternatively, you can set the identifier for your DWork vector directly in your S-function. For more information, refer the following S-function demo:
sfcndemo_sfun_rtwdwork.mdl
Best Answer