Ignition Module

Jump to Section

The Ignition Module connection allows for browsing, reading, and writing tag data and UDTs to and from Ignition. The connection requires that the HighByte Ignition Module be installed on the Ignition server. For details on downloading and installing the module, please see the install section.

With the module installed in Ignition, the Intelligence Hub connects securely to the module using secure web sockets.

Connection Settings

Host

The IP address or domain name of the Ignition server.

Port

The port used to connect. By default the port is 45280. This port must be open and available on the Ignition server.

Password

The password used to authenticate the connection. This is set in Ignition under the module configuration (see module installation).

Connect Timeout (seconds)

How long to wait for a connection before failing.

Request Timeout (ms)

How long to wait for a read or write to complete before failing.

Input Settings

Inputs can be tags, folders, or UDTs from any Tag Provider in Ignition. Input reads are subscribed and serviced from cache during read. If a Tag Provider is changed, for example a tag is added or deleted, the module automatically detects this change and reflects the changes in the next read.

All input types can be used as Event sources. When used as an event source data updates are changed-based using Ignition subscriptions. The _name and _model keys are always included with UDT instances for identification purposes. Reading an input used as an event source returns the latest cached data associated with that address. The Ignition Module buffers tag changes in 100ms intervals to produce data change events. Data changes are not lost unless the journal limit of 10K is exceeded in any given 100ms interval. Event log message are logged any time the data change journal overflows.

Tag Address

The full tag address, as defined by Ignition. This includes the Tag Provider and the path. The address can point to a tag, folder or UDT. When reading a folder or UDT, all child tags, folders, and UDTs are also read. Examples are provided below.

// Read a line and all child data
[default]/site/are/line
    
// Read a tag
[default]/mytag

// Read the entire tag provider    
[default]

Type: Path

Recursively reads the Tag Provider namespace at the specified address and returns all tags, folders, and UDT instances.

Type: UDT Instances

Recursively reads the Tag Provider namespace at the specified address and returns a list of UDT instances according to the UDT Inclusion Filter.

UDT Include Filter

Specifies the User Defined Types to match when searching the specified address. The input always produces a list of UDT instances. If empty, the list contains UDT instances of all types.

Output Settings

Outputs can write to or create tag providers, tags, folders, and UDTs (both definitions and instances). Outputs automatically detect changes to a Tag Provider and reflect those changes on the next write.

Tag Address

The tag address to write to. This address must exist if Create is disabled, otherwise the write fails. Like inputs, the tag address must include the tag provider and full path.

Create

Enable this option to create tag providers, tags, folders, and UDTs if they don’t exist. See below examples of write payloads and how these map to the Ignition Address space.

Do not enable Create to write to existing tag providers that the Intelligence Hub has not created and does not own. In some cases this can lead to a loss of tags or UDTs in the existing tag provider.

Assume all the examples write to [myTagProvider] with Create enabled. If myTagProvider doesn’t already exist, it’s created.

The following write payload will create [myTagProvider]/myTag1 as an integer and [myTagProvider]/myFolder/mySubFolder/myTag2 as a string.

json

{
  "myTag1": 23,
  "myFolder": {
    "mySubFolder": {
      "myTag2": "hello world"
    }
  }
}

The following payload creates a UDT definition named “injection” with temp and cycleCount attributes. It also creates folder hierarchy for line1/area1 as well as two UDT instances named machine1 and machine2.

json

{
  "line1": {
    "area1": {
      "machine1": {"_model": "injection", "temp":  100, "cycleCount": 1},
      "machine1": {"_model": "injection", "temp":  75, "cycleCount": 20}
    }
  }
}

The following payload created a single “injection” UDT definition, and a UDT instance named “injection1”.

json

{"_model": "injection", "temp":  100, "cycleCount": 1}

Installing Module