|On this page…|
SimDriveline provides a conversion utility that you can use to automatically translate first-generation models and libraries to the second-generation format. The conversion utility replaces first-generation blocks with their second-generation functional equivalents. You can manually modify any automatically converted model or library. See Automatic Conversion of First Generation Models and Libraries and Modification and Troubleshooting of Automatically Converted Models.
Manual reconstruction of a model or library is an option. During manual reconstruction of a model, you directly replace each first-generation block with a second-generation equivalent block. You must provide the appropriate input parameters to the blocks. You must also connect the blocks with the appropriate physical connection lines.
Tip Manual reconstruction of a first-generation model requires more time and attention to detail. Streamline the conversion process by using the conversion utility first. Then, after the utility automatically converts your model or library, review for accuracy. You can manually change any blocks and parameters
Almost all first-generation blocks have equivalent second-generation blocks. With second-generation blocks, you can recreate all first-generation functionality. For information about the mapping of first- to second-generation blocks, see Correspondence of First and Second Generation Blocks.
In a first-generation model, every driveline requires a Driveline Environment block. The second-generation equivalent is a Simscape™ Solver Configuration block for each physical network. In this case, a second-generation driveline is a physical network.
You recreate the first-generation driveline connection lines between first-generation blocks by connecting the equivalent second-generation blocks (based on the Simscape library) with mechanical rotational connection lines.
Most of the equivalent second-generation blocks have parameters identical or similar to the parameters of the corresponding first-generation blocks. The primary difference is how first- and second-generation blocks implement signals.
First-generation blocks accept and generate unitless Simulink® signals. Some input signals are normalized by dividing by physical reference values with units. Output signals are converted to physical values and units by multiplying by physical reference values. These values and units are set in the blocks.
Second-generation blocks accept and generate Simscape physical signals that carry units. The blocks accept these units, but do not implement them.
To achieve equivalent functionality in the second-generation model, you therefore might have to redefine your signals and to change how parameters are entered in a block. You can convert between Simulink signals and Simscape physical signals with Simulink-PS Converter and PS-Simulink Converter blocks. If you need to, use the Simulink Gain block to rescale signal values.
With certain blocks, there are also minor technical differences in how parameters are entered. You can determine these differences by comparing the old block and new block reference pages.
The first-generation Controlled Friction Clutch is functionally equivalent to the second-generation Disk Friction Clutch. If you reconstruct the Controlled Friction Clutch with a Disk Friction Clutch, the key parameters and signals that you need rearrange include:
Input signal P (pressure).
The first-generation input is a normalized, unitless Simulink signal that modulates the physical value that the block parameters determine. When this signal value is 1, the kinetic friction across the clutch discs is the full kinetic friction torque implied by the block's parameters. The normalized pressure signal can have a threshold between 0 and 1.
The second-generation input is a Simscape physical signal carrying units of pressure. This signal is used directly in the calculation of the torque applied across the clutch. The physical pressure can have a threshold that you must enter as a physical value with correct units.
Peak normal force Fmax in the first-generation block, which is replaced by engagement piston area A in the second-generation block. In second-generation , you multiply A by input pressure to determine peak force.
Coefficient of friction table μ, or mu, in the first-generation block. In the second-generation block, this option is available. But, as an alternative, you can also use a fixed friction coefficient.
To replace a Controlled Friction Clutch with a Disk Friction Clutch, using the same normalized Simulink signal for pressure:
Place a Gain block and a Simulink-PS Converter block, connected in that order, between the normalized input signal and the Disk Friction Clutch pressure port P.
Set the gain value to Fmax/A. In the Simulink-PS Converter block, set the Input signal unit to Pa (pascal). (If you use a different pressure unit in the Disk Friction Clutch, use that unit here instead.)
Map the old clutch to the new clutch parameters:
In the new block, set Engagement threshold pressure to Fmax/A times the value of Engagement threshold for normalized pressure in the old block.
If the old mu table parameter is a 2-by-2 matrix, and the two friction coefficient values are the same, then set the new Kinetic friction coefficient to the old friction coefficient value. Set the new Static friction coefficient to the old Static friction peak factor times this value.
Otherwise, in the new block, select the Table lookup kinetic friction coefficient option for Friction model. Set Kinetic friction coefficient relative velocity vector to mu(:,1) and Kinetic friction coefficient vector to mu(:,2).
Copy exactly the remaining parameters, or leave them as default in the new clutch.
First-generation models can have specialized features. You might have to perform additional tasks to recreate these features in second-generation format. Some issues to consider are reconstructing initial conditions, modeling physics, removing algebraic loops, and taking advantage of Simscape features not available in first-generation, such as local solvers.
These specialized modeling issues are similar to manually optimizing automatically converted models after translation. For additional guidance, see Best Practices with Automatically Converted Models.