Difference between revisions of "State Variable Inits"

From T-VEC Wiki
Jump to: navigation, search
Line 16: Line 16:
 
The following image shows the vectors that are produced based on the different State Variable Init settings. Based on the rules, the key variable is the '''_local.IState_Unit_Delay''' variable, which is associated with the init setting:
 
The following image shows the vectors that are produced based on the different State Variable Init settings. Based on the rules, the key variable is the '''_local.IState_Unit_Delay''' variable, which is associated with the init setting:
  
* T=0 - _local.IState_Unit_Delay = Initial Conditions from Simulink Block (See Image)
+
* T=0 - _local.IState_Unit_Delay = Initial Conditions from Simulink Block (See Image below, the Initial conditions value is 0)
[[Image:Unit_Delay_Initial_Conditions.png|right|thumb|100px|Initial Conditions]]
+
 
* Ignore - _local.IState_Unit_Delay
+
[[Image:Unit_Delay_Initial_Conditions.png|center|Initial Conditions]]
* T>0 - _local.IState_Unit_Delay values are based on convergence (based on low-bound or high-bound) rather than be initilized or assigned
+
 
* T>=0 - combines rules T=0 and T>0
+
* Ignore - is treated fundamentally the same as T>0. However, it is the default setting when there are no state variables
 +
 
 +
* T>0 - _local.IState_Unit_Delay values are solved for (i.e., through vector generation convergence), rather than initialized to their T=0 values
 +
 
 +
* T>=0 - generates vectors for each DCP individually, first applying T=0 rule and then applying T>0 rule
 +
 
 +
 
 +
 
  
 
[[Image:State_Variable_Inits_and_Vectors.jpg|center|State Variable Inits and Vectors]]
 
[[Image:State_Variable_Inits_and_Vectors.jpg|center|State Variable Inits and Vectors]]
  
 
===Test Driver Mapping===
 
===Test Driver Mapping===
The RTW auto generated code makes these variable visible. Therefore, the following code illustrates how these variables are mapped to specific test driver inputs.
+
The RTW auto generated code makes these variables visible. Therefore, the following code illustrates how these variables are mapped to specific test driver inputs. The two key variables include the input '''test_sequences_U.In1''' and state variable associated with the unit delay '''test_sequences_DWork.UnitDelay_DSTATE_b'''.
  
 
<table>
 
<table>
Line 53: Line 60:
  
 
   fprintf(ofstream, "\n");
 
   fprintf(ofstream, "\n");
 
 
</pre>
 
</pre>
 
</table>
 
</table>
Line 62: Line 68:
  
 
==Example Model - Double State Delay==
 
==Example Model - Double State Delay==
This rationale for being able to verify code with a single state applies to multiple state depths too, as illustrated by the following example that contains two unit delays that are sequence.
+
This rationale for being able to verify code with a single state applies to multiple state depths too, as illustrated by the following example that contains two unit delays that are sequenced.
  
 
[[Image:Double_Time_Delay.png|center|Double Time Delay]]
 
[[Image:Double_Time_Delay.png|center|Double Time Delay]]
Line 74: Line 80:
  
 
===Test Driver Mapping===
 
===Test Driver Mapping===
The RTW auto generated code makes these variable ('''test_sequences_DWork.UnitDelay_DSTATE''' and '''test_sequences_DWork.UnitDelay1_DSTATE''') visible. Therefore, the following code illustrates how these variables are mapped to specific test driver inputs.
+
The RTW auto generated code makes these two state variables ('''test_sequences_DWork.UnitDelay_DSTATE''' and '''test_sequences_DWork.UnitDelay1_DSTATE''') visible. Therefore, the following code illustrates how these variables are mapped to specific test driver inputs.
  
 
<table>
 
<table>

Revision as of 16:23, 28 February 2007