Data Types
At any given point within an adapter script, any piece of data being processed is associated with a general data type. General data types include booleans, numbers, strings, arrays, and objects. There is also a special type that any piece of data can temporarily be in called unavailable.
Data that originates from a data source, such as tags or pins, will have a data type determined by that data
source. These types will usually remain consistent, but depending on the data source, that may not be
guaranteed. Some data sources also require types to be specified as part of their data definitions, such
as the tags on a modbus data source. These types are different, but related, to the data types associated
with data as it's processed in an adapter script. The various specific number types in modbus such as int16
or uint32
for example, will be classified as a number
within the script.
Within a variable definition, each operation will have a specific set of data types it's compatible with, and may output data that's of a different type, passing that to the next operation or assigning it back to the variable. Some operations will accept multiple data types and quietly convert them, which will often be the case with numbers and strings, while others may have different behaviors depending on the incoming data type.
All data that is exported as a data-item or part of a condition will be converted to a string representation to be compatible with MTConnect adapter output.
Data Type reference
Boolean
Boolean values can be either true
or false
. This is equivalent to logic states of high
and low
, and
most inputs that provide a logic input such as digital I/O devices will have a boolean type.
Within expressions, booleans can be used directly in logical comparisons, such as the and
, or
, or not
operators.
Number
Numbers include any integers or floating point values. Most data sources are capable of providing some of their data as a number type, including any readings from analog I/O devices.
Within exprsesions, numbers can be used in relational expressions, such as greater-than or less-than comparisons, and can be used with an assortment of mathematical functions.
String
Strings include any kind of text-based input, but they may also include numbers that are represented in text format. Any inputs from an MTConnect or transform data source will be strings, even if they represent numerical or boolean data. Most operations that require one of those other types will try to convert the data if they get a string.
Within expressions, strings can be compared for equality or used with several text-based functions, such as pattern matching.
When writing a string value directly into an adapter script, it's not normally necessary to surround it with quotes. However, quotes may still be required if the string contains specific character sequences, such as a colon (:) followed by a space. This is a limitation of adapter scripts being valid YAML documents.
Array
Arrays are a list of one or more pieces of data. Each piece of data will have its own data type such as number or string. Usually all elements of the array will have the same data type, but it is possible for a data source to provide an array with mixed types.
Within expressions, arrays can be indexed with square-bracket syntax, such as myarray[2]
or myarray[numvar]
, where
numvar
is an identifier with a number data type holding a valid integer.
There are a few opreations that are specifically for processing arrays, such as map.
Object
Objects are a collection of multiple pieces of data, often of different underlying data types. Each piece of data within an object is called a property and has a name.
Within expressions, objects can be indexed using dot notation, such as myobject.propname
. If the property name
is not a valid identifier name, such as a name that includes dots or spaces, then square bracket indexing can because
used instead, such as myobject['prop name']
. If a property is itself an object, indexing can be chainged, such As
myobject.subobject.propname
.
Other Types
Within an adapter script, some operations may have paramters that are not normal data types, such as patterns and expressions. These are more concept than type, and data itself will never have a pattern or expressions type.
Pattern
Patterns represent regular expressions (regex). Some operations require or optionally accept patterns are a more powerful way to perform matching or replacement. When a pattern is called for, it must be a valid ECMA (JavaScript) regular expression, and should be surrounded by forward slashes (/). For example:
/\d+/
The regex flags i
, m
, u
, and s
can be specified by placing them after the closing slash. The g
flag will
normally be controlled by the operation using the pattern.
Expression
Expressions are used to calculate a value using operators, functions, and one or more pieces of data that can be other identifiers from the script. Expressions are technically strings, but the content of the string is evaluated.
While most strings in an adapter script do not need to be surrounded by quotes, including expressions, quotes may still be required if the expression itself contains specific character sequences, such as a colon (:) followed by a space. This is a limitation of adapter scripts being valid YAML documents.
String Expression
String expressions are strings that can contain one or more expressions within them. When a string expression is
processed, each expression within it is evaluated, with the result replacing the expression within the string.
Expressions must be enclosed using a dollar-bracket syntax (${}
). For example:
The temperature is ${temperature} and the weather is ${weather}
Where temperature
and weather
might be identifiers coming directly from a data source, or might be other
variables defined within the adapter script.
More complex expressions can also be used, for example:
${partcount1 + partcount2} parts
Unavailable
Any identifier within an adapter script can end up in a special unavailable state. Unavailable is a concept from MTConnect, and represents data in an unknown state. The state may be unknown because a data source is not connected to its underlying device, in which case all identifiers coming from that source would likely be unavailable.
Unavaialble is "infectious" within scripts. If any identifier referenced by an operation becomes unavailable, the result of the operation will automatically be unavailable, and this will cascade through the rest of the chain and cause the variable's state to become unavailable. If that variable is referenced anywhere else in the adapter script, the unavailable state will continue to cascade. All operations obey this behvaior, with the exception of the when-unavailable operation, which is explicitly intended to capture the unavailable state and allow it to be handled.
In addition to unavailable items coming from data sources, the unavailable state can arise two other ways:
-
If an error occurs while evaluating any expression, the result of the expression will be unavailable and that state will cascade through the rest of the chain.
-
The exact string "UNAVAILABLE" (all-caps, without quotes) is encountered, it will be considered the same as the item being unavailable. This magic value comes from MTConnect where any data item, regardless of type, can be set to this string to represent an unavailable state.