Click the Edit Table button to edit the list of system-managed services, defining how the RediGate should handle these services. By default, the RediGate will actively manage Linux services — this means if the configuration object is missing or disabled, the RediGate will remove those services. If the object is present (and enabled) in the configuration, the RediGate will configure those services.

However, in some cases, the customer may wish to independently manage these Linux services, such as the IT department taking care of periodic password updates independent of the ACE configurations, or managing other Linux services (Firewall, etc.) from the command line. In these cases, you must add an entry to the Linux Services table and set the option to "Customer-managed service" to prevent ACE from enabling, disabling, or configuring the service.

Service Name – Select the Linux service from the list of available services. Services in the Linux System object include:

Hostname – Configured in the System configuration object. By default, this sets the Linux system name when logging into the command prompt.
User Password – Configured in the System configuration object. By default, this option allows the user password for the user HMI and 'Dirupld' accounts (not the 'root' password) to be configured in ACE. If set to "Customer-managed," configuration updates will not modify these passwords. The 'root' and any other Linux system accounts must always be managed by a system administrator, separate from the ACE configuration.
Timezone – (Date Format) Configured in the System configuration object.
Ethernet (eth0) – EtherPort object with instance 0.
Ethernet (eth1) – EtherPort object with instance 1.
PPP (ppp0) – PPP or CellModem object with instance 0.
Frame Relay/WAN (frame0) – (unused - legacy option)
Firewall & QOS – Firewall object, which configures the /etc/init.d/firewall.sh file. (In legacy systems, this configured the arouter.conf file.)
Route Table (sroutes) – Route Table object, which configures the /etc/network/sroutes file.
DHCP Relay– (legacy option)
DHCP Server – Optional child object under Ethernet.
NTP – NTP Client option.
SNTP – (legacy option)
SNMP
PPP1
DNS (resolv.conf) – Normally configures /etc/resolv.conf if DNS is used on any interface.
SerialMMI (console on ttyS0?)
AutoStart User HMI – By default, the 'user' login displays the user HMI menu. If set to Customer-managed, logging in with the 'user' account will terminate at a command line. The HMI menu can be run manually by typing "MMI".

ManagedBy – Select how the service should be managed whenever a new ACE configuration is downloaded to the unit. Options include: 

ACE should manage service – Uploading an ACE configuration will configure the service (if configured), or delete the service (if not present or object is disabled in ACE). Hostname, User Password and Timezone will be set in Linux according to the properties which appear in the System configuration object. If the Linux System object is not included in the configuration, or if the Service Name option is not present in the table, this is the default option.
Customer-managed service – Override normal configuration handling of Linux services. Uploading an ACE configuration will not add, delete, or configure the services. A user with administrative access will need to manage these services themselves.

Enter a unique instance number between 0 and 16.

The instance number is required to correspondwith the Linux interface name for the Ethernet. Instance #0 and 1 configure the built-in 'eth0' and 'eth1' ports, and Instance #2 configures the 'eth2' port of the optional AIM104-ETHER.

Click the Edit Table button to edit the list of Multi-Home addresses.

Network Card IP – Enter the additional IP address to be used, in dotted notation (do not include the primary IP address defined in the Ethernet object).
Subnet Mask – Enter the Subnet Mask to be associated with this IP address, in dotted notation.
Default Gateway – Enter the Default Gateway to be used with this IP address, in dotted notation.

Enter a unique instance number between 0 and 127.

When configuring physical serial ports, the instance number must match the COM port number in the Linux system. 

For RediGate 1xx series, you must use instance 2 for COM2.

For built-in Zeus processor ports, use instance numbers 0 through 3 for COM0-COM3 (Linux /dev/ttyS0 through /dev/ttyS3).

For the AIM104-COM8 expansion card, use instance numbers 4 through 11 for COM4-COM11 (Linux /dev/ttyS4 through /dev/ttyS11).

To configure virtual serial ports, see the section 2-System and Networking Objects#Virtual Ports. 

Enter a unique instance number between 0 and 127

Virtual Ports must be added in pairs, using instance numbers: 52 & 53, 54 & 55, up to 66 & 67 

Enter a unique instance number between 0 and 18. 

Instance #0 is the configuration for the numbered interface, such as 'ppp0. 

Instance number for each port must be 0.

The ACE template is built so that each of these objects creates the appropriate AsyncPort filename: port073, port075, port077 

Always 0

Must be 0. 

Must be 0. 

The Subnet Mask sets the range of addresses to be defined by this route entry. If defining the Default Gateway (first row of table only), this must be set to 0.0.0.0.

Enter the IP address to use as the Gateway (or Default Gateway, first row only) for addresses defined in this route entry. 

To define a route based on the interface rather than a specific Gateway IP address, set the Metric to one of several specially designated values (90, 91, 100, 101, etc.), as described below. In this case, the Gateway property may be set to 0.0.0.0 to omit the 'gw' field in the Linux route command. (This is for Routes entries that are not the Default Gateway.)

Note that when defining the Gateway property (other than 0.0.0.0), the address of the gateway must be reachable via the networking defined in other ACE objects for the specified interface. 

NOTE: This is a legacy option that is not used by the RediGate.

Enter the text identifier of the network interface to use for the addresses appearing in this route. Note: This is case-sensitive. For instance, if the route entry specifies an address range on the Ethernet network, and the Ethernet object is configured with "Ether1" for its Domain Name, then "Ether1" must be entered as the Interface here. 

The Metric indicates the relative priority when two routes might be used to reach the same network address. The Metric with the lower number will be given priority.

OR, use the following specially designated values in the Metric field to set up a static route based on interface name rather than IP address:

• Use Metric of 90 to use the 'ppp0' interface (91=ppp1, 92=ppp2, etc.)
• Use Metric of 100 to use the 'eth0' interface (101=eth1, 102=eth2, etc.)
• With these designations, the Linux interface name is used in the 'route' entry instead of IP addresses.

Must be 0. 

Enter a unique instance number between 0 and 99. 

Must be 0. 

Must be 0. 

Must be 0. 

In the VLAN Table field, add a table row for every VLAN to be defined. 

Physical Device – Select the physical LAN device to be divided into VLANs, such as eth0 (corresponding to EtherPort object with instance 0). In Linux, the original network interface will be renamed (e.g., eth0 will be renamed to eth0_base) unless the VLAN_ID is 0.

If the interface is renamed to "eth?_base", the IP address settings configured in ACE for that physical device are not used. However, the instance of the physical port still must be defined in order to give Linux a network interface that can be divided into VLANs. 

New Device Name – Select the Virtual LAN device to associate with the Physical Device selected (above). The IP settings for this VLAN device will be taken from the EtherPort object with the corresponding instance number. 

VLAN ID – Enter the numeric VLAN ID to use for 802.1Q tagging (1 to 4094). Use 0 to keep the original interface with untagged packets (i.e. don't rename to eth?_base). It is recommended to avoid VLAN 1.

Must be 0. This defines the interface as 'ppp0'.

The instance number is the next consecutive number, starting from zero. Instance #0 is the configuration for the 'ppp0' interface. There is no correlation between PPP instance number and the physical COM port to which it will be attached. 

Select the physical communication port to be used for PPP.

Do not configure this port as an Async or other type of port in addition to the PPP port configuration. If there are Async and PPP objects defined for the same physical COM port, neither will work properly. 

Select the parity for the PPP port (None, Odd, Even).

Enter value for warm up time.

This is the amount of time to wait before sending data after the RTS handshaking lead has been asserted.

An entry of -1 denotes that no handshaking be used. An entry of 0 denotes that RTS/CTS hardware handshaking will be used (no data will be sent until CTS is asserted, and active CD must be present to receive data)). A positive value will transmit data after the configured number of milliseconds, independent of CTS. 

Enter value for warm down time.

This is the amount of time to wait after the entire message packet has been shifted out to keep the RTS handshaking lead asserted. 

An entry of -1 denotes that no handshaking be used. 

Enter the domain name.

Name used by certain tasks internally to identify different IP adapters. This is case-sensitive. 

Enter the PPP IP address.

This is the address at which other network devices will see this device when trying to make a connection via PPP. If this device is connecting to a PPP device that can automatically assign an IP address, this parameter may be configured as 0.0.0.0. 

Enter the subnet mask.

Should always be 255.255.255.255 for PPP.

If a static IP is used and a Default Gateway is required to make outbound connections beyond its subnet, the Routes object must also be configured (see the section Route). 

Number of seconds to operate a PPP session before killing the connection.

This time is absolute, based on the time at which the session was initiated. The PPP connection will be closed regardless if data is still being transferred when the TimeToDie timer expires. This may be used to force a dial connection to hang up to limit telephone connection charges. Disable the TimeToDie by setting it to -1 if the connection is a permanent hard-wired connection, so that it will never be closed.

Secrets_00
through
Secrets_10

 Enter the Linux 'secrets' entry as a text field. through 
Each Secrets entry must include four text fields separated by a space.

The four fields are:

• Client name
• Server name
• Authentication secret
• Optional IP address (this may be entered as a range of addresses with asterisks, such as ...)

Search for "PPP Secrets" documentation on the Internet for additional information on the format of the IP address field.

Select the network interface through which the HCP should make the primary connection.

Ethernet 0 uses the primary IP network address configured in the Ethernet object (instance 0).
Slip 0 and Slip 1 options are currently unused.
PPP 0 uses the IP network address configured in PPP object 0.
PPP 1 uses the IP network address configured in PPP object 1.

Select the network interface to which the HCP should make a secondary connection whenever the primary connection is unavailable.

The same options are selected as for the Primary network.

Select "No Secondary Connection" if there is only a single IP address/network to which the HCP can connect. 

Enter the time (in seconds) before the HCP should attempt to make connection to the Secondary network address, after losing connection on the Primary network.

This is ignored if no Secondary connection is defined. 

Enter the time (in seconds) before the HCP should attempt to make connection to the Secondary network address, after losing connection on the Primary network.

This is ignored if no Secondary connection is defined. 

Enter the time (in seconds) after disconnecting from the Secondary network address before reconnecting to the Secondary, if the Primary network is still unavailable.

This option may be used to reduce long distance charges by dialing the Secondary network infrequently during a long outage of the Primary network. For instance, the HCP might connect via dial-up PSTN line once or twice an hour to get critical data updates and then disconnect. 

Select the default failover behavior for HCP connections.

Automatic – On startup, the HCP will automatically switch between Primary and Secondary connection paths.
Manual – On startup, the HCP will wait for an operator to manually switch from the Primary to the Secondary connection. This is the default setting for the connection upon first starting the HCP. The Auto/Manual setting for each RediGate can be overridden in the HCP user console at any time.

Select the day of the week on which to initiate Secondary Slave testing.

Select the day, or "Daily" for every day, or "Never" to disable the test. 

Select the day of the week on which to initiate Secondary Slave testing.

Select the day, or "Daily" for every day, or "Never" to disable the test. 

Enter the starting register address to use for writing data.

Starting address should be a 40xxx register. 

When using the SNMP configuration, the command line used is:

/sbin/snmpd -m RFC1213-MIB -M /usr/director/bin/mibs -C -c /etc/snmpd.conf Agent_ExtraOpts Agent_ListenOn

where the Agent_ExtraOpts and Agent_ListenOn properties are inserted before "/etc/snmpd.conf", which contains the remainder of the configuration parameters.

Read-only community name. The RediGate currently only supports read-only community, not read-write community.

Enter a text string between 1 and 63 characters. 

User-defined system description.

Enter a text string between 1 and 127 characters. 

User-defined system location.

Enter a text string between 1 and 127 characters. 

System contact of the individual who manages this system.

Enter a text string between 1 and 127 characters. 

The following parameters are used as command-line arguments for the script which calls the snmpd service. Elecsys uses a standard Linux SNMP agent, and documentation on these properties can be obtained from public sources if extra options might be needed.

Extra command line options for the SNMP agent service may be entered here. Normally, this should be left blank. (Note, this field does not get added to the SNMP configuration file.)

Text string must be 127 characters or less. 

If used, Agent_ExtraOpts should contain valid command options for 'snmpd', exactly as would be used in a Linux command line for starting the SNMP daemon.

This sets the port to listen for an SNMP management system connection. This option is added to the Linux command line.

The default option, 'UDP:161' establishes a server on the standard UDP port 161 to use for SNMP. Multiple ports or protocols (such as TCP) can be added, separated by commas. For example the string 'UDP:161,5000,TCP:2000@localhost' would listen for SNMP on ports 161 and 5000 using UDP protocol, and using TCP protocol on localhost only at port 2000.

Enter the Master Channel name.

This is the name which appears in the user diagnostics menu, and is also see in an HCP diagnostic window if used with Elecsys HCP. 

In some configurations this may be listed as "Direct Master", which includes a few operational differences noted below. The main differences between the Channel Types are listed below:

Direct Master

• Global Scan Period
• One failed poll changes RTU comms status.

Direct Master Flex Scan

• Scan Period configured for each scan.
• All "effective" polls must fail before RTU comms status fails. 

Select the automatic polling method for the channel.

Automatic polling types supported are:

• Yes – polling started automatically upon power-up
• No – polling started manually through the MMI
• Link Based Poll – polling is started only after a P/R connection has been made from an HCP. 

Enter the response timeout in milliseconds.

Time in milliseconds to wait for a poll response before declaring the message failed.

For Network Circuits, if a scan fails because the socket is broken or interface is unavailable, then the Master Channel protocol will wait a period of time (Response Timeout * 2) to try the next IP address in the Circuit. 

Unused.

Enter the interpoll delay in milliseconds. Use this to add a delay between each poll sent by the channel to any field unit.

Time in milliseconds to wait between each poll. 

The Scan Effective Limit is the time (in seconds) defining which scans in the Scan Table are considered "effective" – meaning, polls which affect the status of the Field Unit if there are poll failures. Scan Table entries which have a Scan Period greater than the Scan Effective Limit do not mark the Field Unit offline when the scan fails.

For instance, if the Scan Effective Limit is configured for 30 seconds, then any scans defined with Scan Period <= 30 will be used to mark the Field unit online or offline. Scans with Scan Period greater than 30 will not mark the Field Unit offline even if they fail. The Scan Effective Limit only applies to the "Direct Master Flex Scan Table" version of the channel object.

A Scan Effective Limit of 0 disables this feature, thus all polls will affect the Field Unit status. 

Enter the network recovery period in seconds.

Time period to wait after an RTU fails, before attempting to re-establish communications with that RTU. This will take the device off scan, allowing other devices on the channel to be polled more frequently and not waste as much time retrying a failed device. 

Click the Edit Table button to define the order and selection of polls to be sent to all field units on this channel, independent of protocol. Field Unit configurations (Modbus, etc.) define the protocol-specific nature of the individual polls that are sent.

Only one Unit Address/Poll Record combination can be entered in the Scan Table. Any subsequent table entries with duplicate Unit Address/Poll Record will be ignored.

Scan Table details:

Unit Address - This is the Field Unit Address as configured in each field unit on this Channel. (To force the Scan Table to ignore the Scan Period, enter a Scan Table row with the Unit Address of -1.) 

Poll Record - This is the row number in the Poll Record in the Field Unit definition. The first row in a Poll Table is referenced as record 1. Only those polls which are to be polled continuously need to be listed in this Scan Table. 

Scan Period - Enter the scan period in seconds. The Scan Period is the amount of time to use for scheduling each scan (global for all scans in the Direct Master, or configured per scan row in the Direct Master Flex Scan Table). 

For the Direct Master, the channel will restart the scan table sequence after the Scan Period has expired. If the total time for a given channel exceeds the scan period, the next scan shall be scheduled immediately.

For the Direct Master Flex Scan Table, each poll is scheduled based on its own Scan Period. If the total time required for scans at any point is greater than allowed by the Scan Periods, the scans will operate as fast as possible. 

Setting a Scan Period to a negative number will disable a scan. However, the first entry in the Scan Table for each Unit Address should not be disabled, or it may not correctly set the Alive/Dead status of the unit. 

Comment - Optional column, allowing a descriptive comment to be entered for each row in the table. The Comment field is unused in the configuration.

Select the primary physical communication port for this circuit. 

The selected port must be defined as an object under Networks, where its Async port properties (baud rate, etc.) are also defined (see the section 4-Master Channel#Async Port).

The same port (e.g. COM1) may also be shared with certain other tasks, such as Terminal Server, and may be used with Virtual Ports.

Click the Edit Table button to edit the IP address or list of IP addresses to connect for the Field Unit(s) on this circuit. Entering multiple IP addresses will allow failover connections when one connection fails (all connections made to the same Master Network Port on different IP addresses). 

Destination Address Enter the IP address to connect.

The IP address must be in the same IP network or reachable via the Default Gateway or Route Table configuration.

Interface Enter the network interface over which to connect to this Destination Address. The network interface must match the Interface name in the ACE object (such as "Ether1") rather than the Linux interface name (such as "eth0").

Enter the field unit name.

Unit name is displayed in diagnostic menus and in an HCP diagnostic screen.  

Enter the actual field unit address which is configured in the device being polled.

Valid Modbus addresses 1 to 255.

Click the Edit Table button to edit the details of the RTDB definition.

Point Count – Enter the number of data points of this type to be allocated space in the database.

Field Format – Select the point data format:

Boolean – Boolean
UINT8 – Unsigned 8-bit integer (0 to 255)
SINT16 – Signed 16-bit integer (-32,768 to 32,767)
UINT16 – Unsigned 16-bit integer (0 to 65,535)
SINT32 – Signed 32-bit long integer
UINT32 – Unsigned 32-bit long integer
REAL32 – IEEE floating point (32-bit)
STRING32 – Each field contains up to 32 ASCII characters
STRING256 – Each field contains up to 256 ASCII characters
EVENT – Timestamped event data obtained from field device.

The following field formats are the same as the above but do not generate an RBE flag when the data changes, even if the Field Unit is set to Produce RBEs=Yes.

No-Rbe Boolean – Boolean
No-Rbe UINT8 – Unsigned 8-bit integer (0 to 255)
No-Rbe SINT16 – Signed 16-bit integer (-32,768 to 32,767)
No-Rbe UINT16 – Unsigned 16-bit integer (0 to 65,535)
No-Rbe SINT32 – Signed 32-bit long integer
No-Rbe UINT32 – Unsigned 32-bit long integer
No-Rbe REAL32 – IEEE floating point (32-bit)
No-Rbe STRING32 – Each field contains up to 32 ASCII characters
No-Rbe STRING256 – Each field contains up to 256 ASCII characters

Data Address – Enter the address of the starting register within the RTDB for the Field Format and Count defined on this row.
The RTDB fields must be defined so they are non-overlapping, and there need to be enough data points defined to hold all of the data returned in the Poll Table entries defined for this FieldUnit.
All RTDB database fields (except String types) may hold 32-bit data items, regardless of the data type or address. The RTDB typically uses registers defined in the range of Modbus addresses, although this is not a strict requirement. However, if the RTDB is connected to a Modbus Slave Channel, it does require Modbus addressing to work properly as a slave (see the Modbus Slave Channel documentation).

Comment - Optional column, allowing a descriptive comment to be entered for each row in the table. The Comment field is unused in the configuration.

Click the Edit Table button and add as many rows as necessary to define the desired deadband values for the points in the RTDB.

• Field(Row) – Enter the row number of the field in the RTDB, containing the data point. RTDB row numbers start at 1.
• Offset – Enter the offset into data point address referenced in the field. Offset of 0 refers to the first point number in the RTDB field.
• Count – Enter the number of data points that the deadband limit will be applied to.
• Deadband – Enter the deadband value, which is the amount a value in the RTDB can change before it will be flagged as an RBE. Deadband value is entered as an integer or floating point value, which is handled as an 11-character (max) string. If IEEE floating point format is used, its entry must include a decimal point (such as 11.0).
• Comment - Optional column, allowing a descriptive comment to be entered for each row in the table. The Comment field is unused in the configuration. 

Point Count

Type

Data address

Field 1:

100

Boolean

1

Field 2:

100

Boolean

10001

Field 3:

100

UINT16

30001

Field 4:

100

UINT32

40001

Field

Offset

Count

Deadband

Explanation

3

0

4

205

Deadband for 30,001-30,004, 5% of its range

4

2

1

100

Deadband for 40,003

4

3

1

500

Deadband for 40,004

• Data Address – Enter the starting register number to define default values. This should be a register number that is defined as part of the RTDB. 
• Count – Enter a count of registers, beginning with Data Address, that should be initialized to the same value. 
• Init Value – Enter the value to which the register(s) will be initialized on startup. For Boolean registers, enter a '0' or '1' initial value. For floating point registers, enter the initial value in floating point format. 
• Comment - Optional column, allowing a descriptive comment to be entered for each row in the table. The Comment field is unused in the configuration.

Click the Edit Table button to define any RTDB tags. 

• Register Address – Enter the RTDB register address in the parent RTDB object. 
• Tag Name – Enter an ASCII tag (up to 32 characters). Do not use the following characters: "|" (pipe), "\" (backslash), and "," (comma). Space characters in the tag are converted to underscores.
• Comment - Optional column, allowing a descriptive comment to be entered for each row in the table. The Comment field is unused in the configuration.

Click the Edit Table button to add as many rows as necessary to define the Data Block capability.

• Data Address – Enter the register number of the beginning of each block. This should be a register number that is defined as part of the RTDB.
• Point Count – Enter the number of data points to group together in each block. Ensure the Point Count is not defined larger than the available points in the RTDB field. Data blocking currently supports a contiguous block of data registers using a range of different data types (Boolean, UINT16, UINT32, REAL32), but cannot be used on larger data types (Strings, 64-bit data).
• Comment - Optional column, allowing a descriptive comment to be entered for each row in the table. The Comment field is unused in the configuration.

 0 to 15 (typically 15 is reserved for the Internal Channel, but instance 14 might also be used if a second ISaGRAF RTU is included)

The Internal Channel must have at least Circuit child object defined under it.

The Database Flush (DumpRTDB) object is an optional child under Internal Master. 

Placeholder for the circuit type as 'Null Circuit'.

Enter the field unit name as an identifier for the Field Unit. 

Enter the Field Unit address. This should be a unique address from any other ISaGRAF, Status, or Internal Master field unit addresses on this Internal Channel.

The default address is 3. 

This parameter is a null field to retain compatibility with other field unit objects.

The only option is 'N/A'. 

Enter the starting holding register to contain the communication status for this field unit. Typically, this field is unused for the Virtual Unit.

Each Comm Status takes 5 registers, beginning at the register configured in this parameter. The Comm Status Holdreg for each field unit in a configuration must be defined such that the five registers do not overlap other registers being used.

If the register is defined in the 30,xxx address range, the status values will be stored in the local device's RTDB (i.e., the RTDB defined as a child object to this ISaGRAF Field Unit.

If the register is in the 40,xxx range, the values will be stored in the Status/Control Field Unit RTDB.

The Comm Status Holdreg is optional, and can be set to 0 to disable the storage of status registers.

See the section 5-Internal Channel#Communication Status Registers, for a description of the five Comm Status Register contents. 

Select this option to determine whether to produce a Report by Exception (RBE) flag when data in this unit's RTDB changes.

In the RTDB, for every data point, there are potentially 4 RBE flags associated with every data point. When the data point changes, the RBE flags are set. These flags are used to determine when new data needs to be reported to the HCP. 

Must be between 0 and 256, and should be unique under this Null Circuit among all Status, Virtual, and Internal Master field units.

The Internal Master Field Unit should have a 5-Internal Channel#Modbus RTDB child object defined under it (see page ).   

Boolean

Boolean

Boolean

Single on/off bit occupies a register

8 bit

Take lower 16-bits of an integer register.

16 bit

16 bit

16 bit

Typical 16-bit register type.

24 bit

32-bit

32-bit

Take lower 3 bytes of a 32-bit integer register

32 bit

32 bit

32 bit

Short String

STRING32

STRING32

Long String

STRING256

STRING256

UTF String

Event

Double-Float

64 bit

64 bit

Copy 16-Bit pairs into 32-Bit Regs

16 bit

32 bit

Registers are taken as pairs, and the Src Count should be the numbers of pairs of registers (32-bit entities). (Source registers are little-endian.)

Swap 16-Bit pairs into 32-Bit Regs

16 bit

32 bit

Registers are taken pairs, and the Src Count should be the numbers of pairs of registers (32-bit entities). (Source registers are big-endian.)

Split-Copy 32-bit Regs into 16-bit-Pair Regs

32 bit

16 bit

32-bit register is broken into pairs of 16-bit registers

Split-Swap 32-bit Regs into 16-bit-Pair Regs

32 bit

16 bit

same as above, but swapped

Boolean-Src to 16-Bit-Dest Hi to Lo Bits

Boolean

16 bit

Boolean source registers are taken in groups of 16, with the first register becoming the most-significant bit (MSB) in the 16-bit value.

NOTE: writing to the 16-bit analog register is not supported.

16-Bit-Src to Boolean-Dest Hi to Lo Bits

16 bit

Boolean

16 bits in source register(s) are placed sequentially to Boolean registers, in the order of most-significant bit (MSB=1st destination register) to least-significant bit in each 16-bit word.

For both Boolean-Bit data types, writing to individual RTDB Boolean registers is not supported -- any bit which is written individually will set only that bit and clear all the others.

16-Bit-Src to Boolean-Dest Lo to Hi Bits

16 bit

Boolean

16 bits in source register(s) are placed sequentially to Boolean registers, in the order of least-significant bit (LSB=1st destination register) to most-significant bit in each 16-bit word.

Src Type

Meaning

Trigger Move Data from Local to Src Data

Choose this option to copy data from the Internal Master RTDB (Dest Data location) into another RTDB (Src Data location), based on a trigger value. The Trigger register is the last register in the specified set.
When the Trigger register is set to a non-zero value by any means (external host, ISaGRAF, POD, etc.), then the full Count of registers are copied from the Dest registers to the Source Chan/RTU/Data register location, and the Trigger register is set back to zero automatically.
Thus, if using a Dest Data register of 40,001 (in the Internal Master), and a Src Count of 17 registers, then the Internal Master RTDB register 40,017 is used as a trigger for the move operation.

Trigger Write Data from Local Data to Src Chan/RTU

Choose this option to write data from the Internal Master RTDB to a device on a Source Channel/RTU address, based on a trigger value. The Trigger register is the last register in the specified set.
When the Trigger register is set to a non-zero value by any means (external host, ISaGRAF, POD, etc.), then the all of the registers are written from the Dest registers to the Source Chan/RTU/Data register location using the device's protocol, and the Trigger register in the local RTDB is set back to zero automatically.

Always Move Data from Local to Src Data

Choose this option to constantly copy data from the Internal Master RTDB (Dest Data location) into another RTDB (Src Data location). No trigger register is used.

Always Write Data from Local Data to Src Chan/RTU

Choose this option to constantly write data from the Internal Master RTDB (Dest Data location) to a device on a Source Channel/RTU address/Src Data register whenever this poll is scanned by the Internal Master Channel. No trigger register is used.

Enter the field unit name as an identifier. 

This parameter is a null field to retain compatibility with other field unit objects.

The only option is 'N/A'. 

Select this option to determine whether to produce a Report by Exception (RBE) flag when data in this unit's RTDB changes.

In the RTDB, for every data point, there are potentially 4 RBE flags associated with every data point. When the data point changes, the RBE flags are set. These flags are used to determine when new data needs to be reported to the HCP. 

This parameter is a null field to retain compatibility with other field unit objects.

The only option is 'N/A'.

Must be between 0 and 255, and should be unique under this Null Circuit among all Status, Virtual, and Internal Master field units. 
The Segment Field Unit should have a 5-Internal Channel#Segment RTDB child object defined under it. 

Must be between 1 and 255. 

Click the Edit Table button to edit the details of the RTDB definition.

Point Count – Enter the number of data points of this type to be allocated space in the database.

Point Format – Select the point data format:

• UINT8 – Unsigned 8-bit integer (0 to 255)
• SINT16 – Signed 16-bit integer (-32,768 to 32,767)
• UINT16 – Unsigned 16-bit integer (0 to 65,535)
• SINT32 – Signed 32-bit long integer
• UINT32 – Unsigned 32-bit long integer
• REAL32 – IEEE floating point (32-bit)

Deadband – Enter the deadband value for the points defined on this row, which is the amount a value in the RTDB can change before it will be flagged as an RBE. Deadband value is entered as an integer or floating point value, which is handled as a 15-character (max) string. If IEEE floating point format is used, its entry must include a decimal point (such as 11.0).

Comment - Optional column, allowing a descriptive comment to be entered for each row in the table. The Comment field is unused in the configuration.

Click the Edit Table button to edit the default values contained in the Load/Store parameter table.  

Parameter 1 through Parameter 16 – Enter the value for each parameter defined in the ISaGRAF STORE16 or STORE32 board. Multiple rows defined in the Parameter Table correspond to multiple sequential instances of the STORE boards (in the order of instances defined in the ISaGRAF application). 

Comment - Optional column, allowing a descriptive comment to be entered for each row in the table. The Comment field is unused in the configuration.

When uploading the ACE configuration, the lsaabbcccc file will be created and uploaded separately at the same time.

Click the Edit Table button to edit the default values of the TextStore object.

Text – Enter the text for each field. The text fields are limited to 16 characters per string. 

Comment - Optional column, allowing a descriptive comment to be entered for each row in the table. The Comment field is unused in the configuration.

When uploading the ACE configuration, the staabbcccc file will be created and uploaded separately at the same time.

Must be between 0 for MQClient, between 0 and 1 for MQ_Extra_Clients.  

MQTT Client address list

SSL/TLS 'stunnel' Parameters

(Connect Port=1883)

Accept Connect

Connect To

127.0.0.1

127.0.0.1:1883

address1.mybroker.com:8883

127.0.0.2

127.0.0.2:1883

address2.mybroker.com:8883

127.0.0.3

127.0.0.3:1883

address3.mybroker.com:8883

Must be 0.   

Milliseconds to wait between sending each RBE packet. T

he RBE task periodically checks the RBE flags set for each point in the RTDB to see if data has changed. If so, all changed points are sent to the broker. This parameter defines how often to perform this check. 

Text string which may be inserted into topic strings for RBE messages, to identify the destination MQ-HCP when using multiple HCP's.

The Console_ID text, if configured, is substituted into the 'sys', 'cmd', and 'file' Control Topics in place of the "Console_ID" (see Subscriptions object). If the Console_ID field is left empty, the field is omitted from the subscribe topic string. 

Select the topic publish rule for MQ RBE messages, which are also the rules that will be used by other clients who subscribe to the broker for the RBE data (such as the MQ_HCP).

When publishing RBE messages, the topic always begins with the topic string "RBE", and the Console_ID field configured in this MQ_RBE object. The Console_ID can be used to differentiate different sets of RediGate data into groups within the host/broker topic space.

The topic string can also include the following data specific to this unit configuration (note, each RediGate should be configured with a unique UnitName or UnitAddress to distinguish the topic message space of each gateway):

• "UnitName" or "UnitAddress" (taken from the top level System object in ACE)
• "RTUName" or "RTUAddress" (taken from the Field Unit object)
• and optionally the "ChannelName" or "ChannelNumber" (taken from the Master Channel object). The Channel information can be excluded if all RTUs in this unit have unique names or addresses. 

Select the RBE publish Subscribe Topic Rule from the following options, where HcpId, UnitName, UnitAddress, ChannelName, ChannelNumber, RtuName, and/or RtuAddress in the topic would contain the actual property data in the configuration:

• RBE/HcpId/UnitName/ChannelName/RtuName
• RBE/HcpId/UnitName/RtuName
• RBE/HcpId/UnitAddress/ChannelNumber/RtuAddress
• RBE/HcpId/UnitAddress/RtuAddress

This option is used in systems using redundant MQTT servers. In this case, the MQTT RBE/PR objects in the ACE configuration will use an instance number (0=primary, 1=secondary). 

If only one MQTT connection is used, the MQ_Client/MQ_Rbe_Pr_Handler process may be configured to use the other RBE instance:

Select 'RBE 0 DBM Flag' to use the primary (RBE0) process for MQ_RBE.

Select 'RBE 1 DBM Flag' to use the secondary (RBE1) process for MQ_RBE. In this case, standard HCP RBE/PR connections would be configured to use instance 0. 

If both primary and secondary HCP connections are used in a configuration, the MQ_Extra_Clients/MQ_Extra_Rbe_Pr_Handler process may be configured to use the alternate RBE instances:

Select 'TERTIARY RBE process for DBM' for the third (RBE2) process for MQ_RBE.

Select 'QUATERNARY RBE process for DBM' for 4th (RBE3) process for MQ_RBE. 

This list allows the MQ_RBE process to filter which Channel/Field Unit configurations will report their data using the automatic RBE process. If this table is left blank (or is omitted in older versions of the configuration), then all configured RTDB database fields will report data on all MQTT clients. If one or more rows are entered in the table, then only the configured FieldUnits will be reported through this MQTT Client.

Click the Edit Table button to edit the list of Field Units.

Channel – Enter the channel number (0-16) of the Field Unit to include in RBE reporting.

RTU to Enable – Enter the Field Unit address of the device to include in RBE reporting.

Must be 0.   

Select whether to subscribe to the MQTT 'sys' topic. The 'sys' topic subscription is used to allow a remote host to send system level commands (see MQ_RBE_PR_Handler).

• sys/Gateway/# – issue subscription where "Gateway" is replaced by the Unit Name in the top-level System object (default, if Subscriptions object is omitted)
• sys/HCP_ID/Gateway/# – issue subscription where "Gateway" is replaced by the Unit Name, and HCP_ID is taken from the parent MQ_RBE object.
• Disable subscription to 'sys' topic – this option prevents 'sys' topics from being received on this device from a host. Note that this setting also prevents Health Echo commands, so an appropriate (non-Health Echo) option must be chosen for Host Synchronization. 

Select whether to subscribe to the MQTT 'cmd' topic. The 'cmd' topic subscription is used to allow a remote host to set or control data values in the FieldUnits on this device. This could be used in a situation requiring a field device to be monitored but commands must be explicitly prevented.

cmd/Gateway/# – issue subscription where "Gateway" is replaced by the Unit Name in the top-level System object (default, if Subscriptions object is omitted)

cmd/HCP_ID/Gateway/# – issue subscription where "Gateway is replaced by the Unit Name, and HCP_ID is taken from the parent MQ_RBE object.

Disable subscription to 'cmd' topic – this option prevents 'cmd' topics from being received on this device from a host. 

Select whether to subscribe to the MQTT 'file' topic. The 'file' topic subscription is used to allow a remote host to publish a file to this device via MQTT. This could be used with some additional logic to process configurations or other files.

file/Gateway/# – issue subscription where "Gateway" is replaced by the Unit Name in the top-level System object (default, if Subscriptions object is omitted)

file/HCP_ID/Gateway/# – issue subscription where "Gateway is replaced by the Unit Name, and HCP_ID is taken from the parent MQ_RBE object.

Disable subscription to 'file' topic – this option prevents 'file' topics from being received on this device from a host. 

Select how (or whether) to synchronize MQTT communication with a host system. Synchronization is typically used when this device is publishing through multiple MQTT servers, and one or more hosts is also connected to the MQTT servers. This ensures that the device and the host system are communicating with each other through the same MQTT server, so that commands and data are sent and received directly.

Require Health Echo from host – Host must periodically send out a 'sys' command with Health Echo and this device will respond with an echo, ensuring synchronized communication (default, if Subscriptions object is omitted). If the Health Echo is not received within two times the Keep Alive period configured in MQClient, the MQClient will disconnect from the current MQTT server and try the next address.

Subscribe to 'STATE/HostName' – (see Host Name option below) This synchronization method reduces network traffic by not requiring constant application-level Health Echo messages. 

In this case, the host should publish a message (with Retain flag set) with topic of "STATE/HostName" (where "HostName" is configured to identify the host). The payload of the message should be "CONNECTED" (all caps). It should also lodge a Last Will and Testament with the server using the same topic and a payload of "DISCONNECTED."

When a RediGate device connects to the server and subscribes to 'STATE/HostName', the server will deliver the retained message immediately with the payload "CONNECTED", thus informing the device that the host application is currently connect on the same server.

If this STATE message is not received within two times the Keep Alive period, the MQ Client will move to the next server. If the server disconnects from the server, the RediGate will receive the "DISCONNECTED" message and will immediately move on to the next server, attempting to locate a server to which the host is simultaneously connected.

No Host Synchronization – If only a single MQTT server is used, this option can be used. The MQ Client will not look for a Health Echo or STATE message but will remain connected to the server. Synchronization with a host is ensured as long as the host is also connected to the server. 

Select how to publish data on startup or upon reconnection to an MQTT server.

Send Only Non-Zero data registers – Upon connection, publish only non-zero values in RTDB registers (default, if Subscriptions object is omitted). Upon receiving the Birth Certificate from this device, the host must zero its entire database of values, so that non-zero data received from the device will ensure host and device have identical data. This option reduces the amount of published traffic upon connection.

Send All data including Zero/Null registers – Upon connection, all RTDB registers (except those configured as "Non-RBE") will be published even if they contain zeroes. This causes more data traffic on reconnection, but it ensures the host is informed of all available points, values, and identifications (tags or register numbers) at the time of connection. 

Select whether to publish tag names associated with RTDB register locations. Publishing registers with tag names requires the configuration of the optional Tag Names object under each RTDB (see 4-Other Client Services#Tag Names).

Don't Publish Tag Names – Upon connection, publish only RTDB registers by number (default, if Subscriptions object is omitted). Upon receiving the Birth Certificate from this device, the host must zero its entire database of values, so that non-zero data received from the device will ensure host and device are in synch.

Publish Tag Names on MQTT Connect – Upon connection, publish a list of the configured Tag Names associated with RTDB register addresses for the Field Unit. Subsequently, all data will be published using the RTDB register addresses, but the host system can use the initial list to correlate addresses with names for display purposes.

Publish GZIP'd Tag Names on MQTT Connect – Same option as previous, but the initial publication of Tag Names and register addresses is sent in the MQTT payload in zipped format using 'gzip' compression. This reduces the bandwidth and packet size when publishing a large database of tag names. 

NOTE: If any RTDB is configured to report by exception using Sparkplug-B but has no tag names configured, then all data for all RTDBs will be published, using their tag name (if available) or RTDB address. To prevent non-tagged registers from being published, make sure that all RBE RTDBs have at least one tag name configured.

Enter the Host Name to use in the 'STATE/HostName' subscription, if using that option for Host Synchronization

Host Name must be a maximum of 80 characters. If using the State/HostName option and this field is left blank, the Host Name in the subscription will default to the HCP_ID in the MQ_RBE object.

Must be 0.

Select which of four RBE flags to use for checking changed data (make sure not to use the same as any other process that might use the same RBE flag, such as MQTT, HCP, DNP).

The STATE topic is used to ensure an active end-to-end connection to Host, or switch to next MQTT server. In applications where the SCADA server and RediGate connect sequentially to more than one redundant MQTT broker, the SCADA server should publish the STATE topic to ensure the RediGate is in active communication using the same broker at the same time, to ensure RBE messages are received end to end. The RediGate will subscribe to the STATE topic, and if it doesn't receive 

To disable the use of the STATE topic, enter a string between 1 and 5 characters in length. Regardless of configuration, the STATE topic is ignored if the RediGate is only configured for a single MQTT server in the URL_List table.

The STATE topic is presently supported on the RediGate using the "legacy" format prior to the Sparkplug-B protocol version 3.0.0, where the payload is expected to be simple text as "ONLINE" or "OFFLINE". The STATE topic should be in the form "STATE/Host1", where "Host1" is the Primary Host ID in the Ignition MQTT Engine or equivalent in a different SCADA system (in MQTT Engine release 4.0.14 or later, also configure the Legacy Host ID - see STATE message in Sparkplug v3.0.0).

Must be 0.

Enter one or more IP address of the NTP servers to which to connect.

NTP uses algorithms to average the errors between different time servers, and to detect servers which are not reliable. If any server address is set to 0.0.0.0, all subsequent addresses in the list are ignored.

A couple of publically available NTP servers you can try are 129.6.15.28 and 129.6.15.29

Use a unique Instance number for each Terminal Client object. 
The Terminal Client object must have at least one child Host Connection object defined. 

From the dropdown list, select the serial port which should be used for connection to this Terminal Client TCP network port. Select the Serial Port from among standard serial ports (COMx) or one instance of a pair of Virtual Port pair (VirCOM xxa or xxb) if connecting this Terminal Client port to another process using Virtual Serial Ports. Make sure the Async port is defined under Networks. 

Select the connection mode of the Terminal Server.

Always – Select this option to connect automatically upon system restart or upon the IP socket connection being terminated.  If using the "Always" mode of connection, there must be only one child Host Connection object with its Dial String set to an empty field. The Terminal Client will use the IP address of that Host Connection object to automatically connect to the end device. 

Any Data – Select this option to connect the Terminal Client to the remote server only when data is received on the serial port. If using the "Any Data" mode of connection, there must be only one child Host Connection object with its Dial String set to an empty field. The Terminal Client will use the IP address of that Host Connection object to connect when data is received on the serial port.

ATDT – Select this option to connect the Terminal Client only if an "ATDT###" message is received on the serial port, where ### is some alphanumeric string. When using the “ATDT” option, there may be many child Host Connection objects defined under this Terminal Client object.  The Host Connection entries should have their Dial String configurations set to unique ATDT### values. The “ATDT” option causes the Terminal Client to act as a modem emulator.  The connected serial device acts as if it were connecting using a dial-up modem, where each ATDT dial sequence tells the Terminal Client to connect to a destination IP server, rather than dialing over a PSTN telephone network.

DCD – Select this option to connect the Terminal Client only when the DCD signal on the RS-232 serial port is raised to a positive voltage.  This option allows a physical voltage input on the serial port to trigger the network socket connection. If using the “DCD” mode of connection, there should be only one child Host Connection object with its Dial String set to an empty field.  The Terminal Client will use the IP address of that Host Connection object to connect when the DCD control signal is received.

ATDT or DCD – Select this option to connect the Terminal Client in one of two modes described above (the “ATDT” or “DCD” modes). When choosing this option, it is required that one or more Host Connection objects be defined with a configured Dial String, and there should also be only one Host Connection object defined with its Dial String set to an empty field. If an “ATDT###” message is received on the serial port, the matching Host Connection object is used, and the Terminal Client connects to that IP address. If an active DCD signal is present, the Terminal Client connects to the IP address defined in the first Host Connection object containing an empty Dial String field.

Number of seconds to close socket after inactivity (0 disables TTL)

After 2019, serial buffer is flushed upon TCP connect if TTL > 5.

Use a unique Instance number for each Host Connection object. 

Enter the Dial String, if applicable, in the form “ATDT###”, where ### is some unique alphanumeric string (up to 30 characters).  This field may be left blank.

If using the Terminal Client in “ATDT” or “ATDT or DCD” connection modes, enter the ATDT#### string that is used to make a connection.  Each ATDT string should be configured should be unique among all Host Connection objects under a given Terminal Client.

The Dial String has an alternate function when using the Terminal Client to connect to a named server (URL, FQDN). If the Connection Table IP address is set to 0.0.0.0 and Interface set to "DNS", then you can enter a URL in the Dial String field.

If using any other connection mode, leave this field blank.  In those cases, the IP address(es) defined in the Connection Table become the default IP address used by the Terminal Client to which connection is made.

Select from the dropdown menu the conditions under which the Terminal Client should disconnect from the IP network server:

Never – Never terminate the Terminal Client from the remote server (remote side can drop the connection at any time).

+++ - Disconnect Terminal Client connection from the remote server if the string "+++" is received on the serial port. This must be exactly three pluses in a row. This function emulates the modem attention string often used prior to hanging up a PSTN dial connection.

DCD Drop – Disconnect the Terminal Client from the remote server when the DCD input on the RS-232 serial port goes to a low (inactive) state. This can be used in conjunction with the DCD connect option in the Terminal Client, to allow the DCD signal to both connect and disconnect; however, the two configuration options are independent and don't have to be used together.

+++ or DCD Drop – Disconnect the Terminal Client from the remote server either upon receiving the string "+++" on the serial port, or when an inactive DCD signal is detected on the serial port. 

Select whether to echo all commands. The options are:

No – Do not echo characters typed from the serial port. To Async – Echo characters to serial port only. To Async & IP – Echo characters received on the serial port to both the serial port and the remote connected IP server. 

Click the Edit Table button to define the IP address(es) and network interface for the Host Connection object.

Destination Address – IP address for the Terminal Client to connect to. Configuring a list of more than one IP address provides a fail-over connection in case one connection is unable to connect.

Interface – Device interface, which must match the Domain Name in the ACE network configuration objects, such as Ethernet, PPP, etc. (case-sensitive). This tells which interface to use for the connection.

To use a named server as the destination (URL or FQDN up to 30 characters) in the Terminal Client instead of an IP address, the following things must be configured:

• Destination Address must be 0.0.0.0
• Interface must be DNS
• Dial String must be the URL address of the connection

The DNS feature currently only supports a single URL destination (not multiple failover addresses). Also make sure under Networks to configure the "DNS Servers" object or enable the "Use Peer DNS" option in the CellModem object.

Must be 0.

Click the Edit Table button to define the variables and corresponding values that will be usable in other areas of the configuration

Search Name: Variable name for string replacement. This value will be accessible within an MQTT Client object by typing the name ${Search Name}

Replacement Text: Up to 512 chars to replace the original ${Search Name}

Returns the System → Unit Name of the current configuration

Must be 0.  

Must be 0.  

Select the COM port on which the Serial MMI will run. NOTE: This should be left at the default setting of COM0. 

Select whether to display standard diagnostic messages on startup. 

Choose 'Yes' to turn on display of diagnostic messages after startup, even if the user is not logged into the Serial MMI.  Choose 'No' to turn off display of startup messages. Diagnostics may still be viewed in the Diagnostic Services menu of the Serial MMI. 

The Inactivity Timeout determines the time between the last keypad activity until the user is automatically logged out the diagnostic menu session. Enter the timeout period in minutes. 

If the Inactivity Timeout is set to 30 minutes or greater, it has a special effect on the user diagnostic option for Custom Reports – the "seconds to delay between refreshes" when viewing a Custom Report can be specified in the range of 1 to 600 seconds. If the Inactivity Timeout is less than 30 minutes, then the Custom Reports refresh rate can only be specified between 5 and 60 seconds.

Must be between 0 and 1000.

Enter the text to be used as the title of this Custom Report. Title should be text from 1 to 32 characters.

Click the Edit Table button to enter the list of RTDB registers to be included in the Custom Report. Report Table fields are: 

Editable – Select whether to allow a user to change the value in the data address. In all cases, the data in the register may be viewed by the user. Options are:

• Display Only – Data may not changed.
• Write to DBM – Data may be written to the RTDB register.
• Write to RTU – Data may be entered by the user, and when entered, the value will be written to the Field Unit associated with the RTDB, based on matching the register number in the Custom Report with the first Poll Table entry in the Field Unit definition.

Label – Enter the label used as an identification for this register when viewed in the Custom Report. Label must be between 1 and 20 characters. If the Label is only a period character, only the register value will be displayed in the Custom Report (no label, and no equal symbol for "Display Only" value). If the previous row uses the "Continue on this row" option for NewLine, this will concatenate the data in this register with the previous one – this may be useful for concatenating multiple consecutive string registers together.

Format – Select the default display format for this register in the Custom Report. 

• Boolean [3] (On /Off) – display Boolean value as On or Off.
• SINT16 [6] – display as signed integer.
• REAL32 [12] (can be 2 INT16) – display as a 32-bit floating point. If the DataAddr register is a 16-bit integer, then two registers are taken and used as a 32-bit floating point value. (When used with "Swap" option in Custom Report menu, the high and low words can be swapped in the display.) Otherwise, the float value can be taken from a 32-bit register.
• Decimal Digits [2] – Display number with leading zero as only two digits (useful for displaying values such as hour, minute, second, so the positions are fixed)
• String-8 [8] (can be 4 INT16, or 2 INT32) – Display 8-character string value. If DataAddr is a String RTDB register, the string value is taken from the first 8 characters. If DataAddr is a 32-bit or 16-bit register, either 2 or 4 registers are taken, and the contents are used as 8-bit ASCII values.
• Short Hex [4] – Display 16-bit integer as 4 hexadecimal character.
• Long Hex [8] – Display 32-bit value as 8 hexadecimal characters.
• UINT16 [5] – Display 16-bit integer as unsigned (0 to 65535).
• UINT32 [12] – Display 32-bit value as long integer.
• Text Only [0] - Label with no value – Ignore Channel/RTU/DataAddr fields and only display Label in the Custom Report with no "=" symbol or value – this can be used to add text headers for the report for visual effect.
• Binary bits [16] – Display 16-bit integer as binary bits (1 or 0).
• Graph [50] (Value between 0 and 100) – Display a text-based graph (using up to 50 '#' symbols), showing the relative value of the number between 0 and 100. Should be used with "Next field on New Line."
• REAL64 [16] – Display 64-bit floating point number, using FLOAT64 RTDB register.
• QualityOfReg [4] (Good/Bad ) – Display "Good" or "Bad" for the quality flag associated with each data point.
• String RegCnt append to Label – 
• UINT64 [16] – Display as 64-bit floating point.

Channel – Enter the Channel number where the RTDB is located (either a Master Channel or Internal Channel).

RTU – Enter the Field Unit address associated with the RTDB containing the data address (defined under the Channel, above).

DataAddr – Enter the RTDB register address of the register to be displayed in the Custom Report.

NewLine – Select how to display the next entry in the Custom Report:

• Next field on New Line – the next entry will begin on a new row
• Continue on this row – the next entry will display to the right of this one

Comment - Optional column, allowing a descriptive comment to be entered for each row in the table. The Comment field is unused in the configuration.

Must be between 0 and 16. 

The Async Slave Channel must have at least one Slave Attach object defined. 

Select the slave type for this Modbus Async Slave Channel. 

Slave types are: 

'Binary Modbus 32 Slave Service' – The Modbus 32 slave service supports the standard Modbus register types as well as 32-bit registers. If any attached Field Unit being polled includes a register of 32-bit data type, the Slave Channel will return one register of 4 bytes. 'Binary Modbus Slave Service (16 Bit Pair)' – The Modbus 16-Bit Pair service supports only standard 16-bit Modbus protocol register types. If any attached Field Unit being polled includes a register of 32-bit data type, the Slave Channel will map each RTDB register into 16-bit register pairs in the Modbus protocol response. 

Must be between 0 and 1000.  

Enter the Modbus slave address that will respond on this slave channel The Slave Address must be a valid Modbus address (1 to 255), and must be unique for all Slave Attach Lists on this Slave Channel. 

Must be between 0 and 16. 

The Network Slave Channel must have at least one Slave Attach object defined.   

Select the slave type for this Modbus Async Slave Channel. The "Little Endian" types indicate that the least significant 16 bits occur first in the message. The "Big Endian" type indicate that the most significant 16 bits occur first. Slave types are: 

'Modbus 32bit Little Endian Word Slave Service' or 'Modbus-TCP 32 bit Slave Service' – The Modbus 32 slave service supports the standard Modbus register types as well as 32-bit registers. If any attached Field Unit being polled includes a register of 32-bit data type, the Slave Channel will return one register of 4 bytes. 

'Modbus 16bit Little Word Endian Slave Service' or 'Modbus-TCP 16 bit pair Slave Service' – The Modbus 16-Bit Pair service supports only standard 16-bit Modbus protocol register types. If any attached Field Unit being polled includes a register of 32-bit data type, the Slave Channel will map each RTDB register into 16-bit register pairs in the Modbus protocol response. See 5-Servers#Async Slave Channel for an example. 

'Modbus 32bit Big Endian Word Slave Service' or 'Modbus-TCP 16 bit pair BIG ENDIAN Slave Service' – Same Modbus 32 slave service as above, but using "Big Endian" type. 

'Modbus 16bit Big Endian Word Slave Service' or 'Modbus-TCP 32 bit BIG ENDIAN Slave Service' – Same Modbus 32 slave service as above, but using "Big Endian" type. 

Must be a unique instance number from other Terminal Servers. 

The Terminal Server must have a TSPORT slave object defined.