Using CD-Tire in a MotionSolve Model

In order to model a CD-Tire in MotionView and MotionSolve the following items are required to be in the deck submitted to the solver:
Item Description
Tire File A tire file, containing the tire data mode, typically obtained from a test lab or a tire supplier.
Road File A description of the road surface used in the simulation.
Tire Force Statement MBS element that represents the tire forces, the GFOSUB.
Tire Orientation A series of markers that orient the tire, referred to on the GFORCE statement.
Requests Requests for information on the tire behavior. A variety of forces and states are available, in several different coordinate frames.
Strings Strings identify a variety of files and data that are required by the solver.

A tire system containing a complete CD-Tire definition is planned for a future release of MotionView.

Using an Existing ADAMS (.adm) File to Run in MotionSolve

An existing .adm file written from ADAMS/car or ADAMS/view should not require any modifications to run in MotionSolve.

CDTire User Defined Road

The ability to define user roads is an important feature of tire modeling: CD-Tire together with MotionSolve (starting with version 10.0 SA205) is able to support user defined roads.
The process of defining and using a user defined road requires:
  1. Creating a user road dll by compiling and linking a series of user road source files.
  2. Selecting the user road option (1100) in the GFORCE user parameter list.
    <Force_Vector_TwoBody
   id                  = "20"
   label               = "CDTire2"
   type                = "ForceAndTorque"
   i_marker_id         = "1621"
   j_floating_marker_id= "2305"
   ref_marker_id       = "7"
   usrsub_param_string = "USER(838,1611,1612,1613,1614,2303,2200,2,4,1,1,20,21,1100,21)"
   usrsub_dll_name     = "cdtire"
   usrsub_fnc_name     = "gfosub"
/>
  3. Defining the appropriate user road file name string corresponding to the road files that you want to use.
    <Reference_String
   id                  = "25"
   label               = "CDTire2_roadfile_root"
   string              = "./prop_files/cdt_data/road_data/rsm1_"
/>

    The user road file will be opened by CDTire and its file I/O unit will be passed as an argument to the user road dll entry function.

  4. Defining the user road dll function name string to contain dll_name and function name separated by double colons (::).
    <Reference_String
   id                  = "16"
   label               = "CDTire1_user_road_dll_fname"
   string              = "cdt_zbuser::ZB1100"
/>

    The above snippet corresponds to an example model that will attempt to load a user dll called “cdt_zbuser.dll” and will attempt to call a function named “ZB1100”. If the loading and the calling part fails, for example due to unavailability of the dll or missing ZB1100 export symbol, the process will be halted.

The compilation and linking of the user dll is a crucial step in order to be able to successfully execute a user road simulation. In order to accomplish this, you need to write a user road function. The user function will be called by CDTire and it must have a defined signature: 
SUBROUTINE ZB1100( X, Y, Z, MUE, IBINIT, INSTANCE, IUNIT, OUNIT, IERR )
The CDTire dll will call the user road dll and expects the user road function to have the following arguments:
INPUTS: X, Y ....... Road coordinates relative to P5 marker in [mm]
        IBINIT ..... Initialization flag ( =0 init, <>0 eval )
        INSTANCE ... CDTire instance number ( PAR(8) of GFORCE )
        IUNIT ...... FORTRAN unit of road data file, already open
        OUNIT ...... FORTRAN unit of road log  file, already open
 
OUTPUTS: Z ......... Road surface height in [mm] at (X,Y) relative P5
         MUE ....... Friction coefficient of road surface at (X,Y)
         IERR ...... Error flag ( =0 success, <>0 stop calculation )

You can write the user road in FORTRAN or C/C++, however the calling function will always pass file units as integers, as opposed to user road file names as strings.

You are responsible for defining the necessary dependencies if the user road function calls mathematical or MotionSolve utility functions, in order to satisfy the linker. Finally, you will also have to ensure that the dll is exporting the entry point name (ZB1100 in this case). The exporting of a symbol from a dll can be accomplished in various ways not described here.