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>

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

An ellipsis (...) indicates the omission of a section of a statement, typically to provide a shorter version of a more complex syntax.

<Sensor_Event
       …  >
</Sensor_Event>

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>

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
...          ...          ...

Only the field code was displayed and wouldn't convert to the image.

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"] 
       ...  >
</Sensor_Event>

When a syntax element consists of a number of alternatives, the alternatives are separated by vertical bars ("|"). When one member from a set of choices may optionally be chosen, the alternatives are listed within double square brackets ("[[" and "]]"). In the example shown below, any combination or none of the keywords STEPSIZE, DT, and HALT may be chosen:

<Sensor_Event
         ID = "integer"
      [[ stepsize = "real" | DT = "real" | HALT ]]
         ...  >
 </Sensor_Event>

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

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

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]])"  
  
    }
   
     [ compare               = { "GE" | "LT" | "EQ" } ]
   
     [ evaluate_id           = "integer"       ]
   
     [ error_tol             = "real"          ]
   
     [ return                = { "TRUE" | "FALSE" } ] >
  </Sensor_Event>