Notation and Syntax

MotionSolve input format is based on the Extensible Markup Language (XML). The input format is called MotionSolve XML. This section describes the notation and syntax for MotionSolve XML. It also describes how MotionSolve XML files may be generated.

A MotionSolve XML file is divided into elements. Each element defines a specific MotionSolve modeling or command element. Elements are delimited in standard XML fashion:

<Element_Name
      …
</Element_Name>

or abbreivated as:

<Element_Name
      …
/>

or abbreviated within a line:

<Element_Name … />

An ellipsis (...) indicates the omission of a section of a statement, typically to provide a shorter version of a more complex syntax. In case a modeling or command element has a nested element, the outer element cannot be written in an abbreviated form.

A MotionSolve XML element contains a set of attributes specific to the modeling or command element being defined. Elements, attributes, and their values are always shown in blue in the manual.

MotionSolve XML attributes are not case sensitive. The following are all equivalent to the solver:

SENSOR_EVENT, Sensor_Event, sensor_event

The convention that is typically followed in MotionSolve is:

Element names are in upper camel with an underscore separating the different words. For example:
```
Sensor_Event, Body_Rigid, Param_Transient, Reference_Marker
```
Attribute names are in lower case. For example:
```
stability, mass_unit, integrator_type, inertia_xy
```

An attribute may have one or more values associated with it. Generic values are typically shown in italics as demonstrated below:

<Sensor_Event
       ID = "integer"
       …  >
</Sensor_Event>

Occasionally, an attribute may have a list of values. The values are separated by one or more blank spaces. For example:

<Contact
       ...
       i_graphics_id = "123 456 789 321 654 987"
       ...

/>

White space between keywords is treated as a delimiter by the XML parser. For the sake of clarity, this manual always lists each keyword in a new line, however the following are equivalent:

<Reference_Variable
       id   = "1"
       type = "EXPRESSION"
       expr = "VX(301)"
/>

<Reference_Variable id="1" type="EXPRESSION" expr="VX(301)" />

White space between a keyword and its value are ignored by the XML file parser. The following are equivalent:

...          ...          ...
id = 1234    id=1234      id   =   1234
...          ...          ...

Square brackets ("[" and "]") indicate optional attributes. The "[" and "]" are not part of the element; they are there merely to express the fact that the attributes and its value are optional. For example, in the following statement, the attribute label is optional. This is shown syntactically as:

<Sensor_Event
       id  = "integer"
      [label = "This is a label"]
       ...
/>

When one member from a set of choices must be chosen, the alternatives are listed within braces ("{" and "}"), and the values are separated by “|”. In the example shown below, either EXPRESSION or USERSUB must be chosen:

<Sensor_Event
       id   = "integer"
       type = {"EXPRESSION" | "USERSUB"}
       …

/>

Attribute Values

Attributes may have several different kinds of values. The required value type is always indicated in the format specification for the modeling and command element.

string implies that the value of the keyword may be any string.
integer implies that the value must be an integer. Real valued data, if provided where integers are needed, are cast to integer format before they are stored.
real implies that the value should be a real number. Scientific notation may be used to express real valued data. Integer valued data, if provided where real values are needed, are converted to reals before being stored.
motionsolve_expression implies the value should be a legal expression that MotionSolve can understand.
valid_path_name indicates that the value is the complete path name for a specific file. The conventions for this are different for different operating systems.
boolean values are indicated by "TRUE" or "FALSE". These are never italicized.
When the value is a specific string or it is shown within "double quotes"; the value itself is not italicized.

A keyword value may not contain white space or be split into separate lines. The following are illegal definitions for keyword values:

...         ...
ID.=.1.234  HALT="T.RUE"
...

User Subroutine Parameters

usrsub_param_string = "USER(par_1, ..., par_n)"

Example

Below is an example of the complete format specification for the SENSOR_EVENT modeling element. Blank lines are added to improve the readability of the document. They are not required.

  <Sensor_Event 
      label                 = "string" 
      id                    = "integer" 
      value                 = "real" 
   { 
      type                  = "EXPRESSION" 
      expr                  = "motionsolve_expression" 
    | 
      type                  = "USERSUB"  
      usrsub_dll_name       = "valid_path_name" 
      usrsub_param_string   = "USER(par_1, ..., par_n)"   
    | 
      type                  = "USERSUB"  
      script_name           = "valid_path_name" 
      interpreter           = {"string"} 
      usrsub_param_string   = "USER(par_1, ..., par_n)"   
   } 
     [compare               = { "GE" | "LT" | "EQ" } ] 
     [evaluate_id           = "integer"] 
     [error_tol             = "real"] 
     [return                = {"TRUE" | "FALSE"}] 
 />