The system name must be a unique name in your project (no systems, commands, macros or feedback parsing can have the same name). When entering the name details, the OK button will be disabled if the name is already in use within the project.
The system name will be used to identify the system within the System Manager tree.

The IP Address of the system is used to connect to the system via the chosen protocol and port number, to send commands and receive feedback. DO NOT enter leading zeros for parts of the IP address which may be below 100. For example, enter 192.168.0.10, NOT 192.168.000.010.
You can also create a loopback system by using IP Address 127.0.0.1. A loopback system allows you to send any command directly back to the device itself, and use this data for feedback parsing.

There are two port settings available for each system, the destination port (labeled simply 'port') and the origin port.
The destination port is the port number the external system is accepting connections on, whilst the origin port is the port number that iViewer is sending messages from. Some systems require commands to be sent to a specific port, but replies are sent on a different port (common amongst UDP systems mainly).
You only have to enter the 'Port' setting most of the time (the origin port will use the destination port setting if it is not explicitly set).
The port numbers must be in the range 1 to 65535. See http://www.iana.org/assignments/port-numbers for more details on port number usage in general.

Systems can use either TCP/IP or UDP as the method of communication. Simply select which one the specific external system uses (some systems even have options for both TCP and UDP, so you can implement two unique systems in your project if this is the case).

When this setting is enabled, the Viewer running the GUI project will attempt to connect to the system on startup, and maintain the connection if any dropouts occur by attempting reconnection every 3 seconds.
When this setting is disabled, the connection is only established when a Command or Macro needs to be sent, and is disconnected again a short time after the command/macro has finished sending.
We recommend always enabling this option unless you have a reason not to - it makes sending commands and macros much quicker, with less latency.

Some systems require a heartbeat message to be sent every so often to ensure the connection is kept alive. The 'Heartbeat managed by system' checkbox works alongside the 'Heartbeat Rx' and 'Heartbeat Tx' properties.
When this option is ticked, the Viewer will reply to any 'Heartbeat Rx' messages with the 'Heartbeat Tx' message (if both are defined).
When this option is unticked, the Viewer will be responsible for managing the heartbeat, and will send the 'Heartbeat Tx' message every 3 seconds. If no 'Heartbeat Rx' message is detected within 10 seconds, it will close the connection and attempt to reconnect.
If both Heartbeat Rx and Heartbeat Tx are not defined, no heartbeat management will take place (most common).
Hex data must be entered in xFF format, see Entering Hex Data for more details.

Feedback parsing works best when an EOM string is defined for the system. Most systems end each message with a unique character (or string of characters). A common example is a carriage return (x0D).
By entering the EOM string used by the system, it allows the feedback from the system to correctly split up each message and parse each message through the feedback system (comparing against feedback Regular Expressions, etc).
If no EOM string is used by the system, messages will be declared a single message when they arrive on the ethernet stack. If the system sends lots of messages quickly, this could result in multiple messages being concatenated or split in strange places, causing the feedback parsing system to not work as expected in some cases. So if possible, always enter the EOM string for your specific system.
Note: The EOM string is NOT appended to outgoing commands for the system. It is only used for splitting up messages when feedback arrives.
Hex data must be entered in xFF format, see Entering Hex Data for more details.

For systems using TCP/IP, the 'connection join' will be held high as long as the system is currently connected.
The connection join number relates to a digital join, and can then be assigned to a button to show connection status (for example).
As soon as the connection fails, the join will go low.

Similar to the Join, but the 'disconnection join' will always be the opposite value to the Join.
This join number will be raised high as long as the system is not connected. A perfect use of this property is to show a subpage when the system is not connected.

Each system can specify a command to be sent every time the system is successfully connected to. This allows you to send login information (required by some systems) or simply send a request for feedback status.
When creating a system, there are obviously no commands associated with it - so you need to first add the system and create some commands, then go back and edit the system by double clicking on the system name in the System Manager tree.
If no startup command is required, simply select 'None' from the drop down list.