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.

Choose an ethernet communication protocol. Options are:

• TCP
• UDP
• HTTP
• HTTPS

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 enter a hostname. 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 (source 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.
Note that you cannot use UDP ports below 1024 on Android platform. This is a limitation of Android.

If the origin port is set to 0, it will use the same port number as the destination port.
If the origin port is set to -1, iViewer will randomly assign an available source port - but ONLY if the system is not set to accept incoming data (it will use the destination port in this case).

When in UDP mode, this allows the system to receive UDP broadcast packets.

When using the TCP protocol, this option will create a TCP server rather than a TCP client.

Used when in TCP server mode, this controls the number of clients that can connect to the TCP server. 0 = unlimited.

Queue up messages for offline systems. If unticked, messages will be discarded when system is not available.

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 Mode dropdown menu works alongside the Heartbeat Rx and Heartbeat Tx properties.
When reply mode is selected, the Viewer will reply to any 'Heartbeat Rx' messages with the Heartbeat Tx message (if both are defined).
When initiate mode is selected, 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 7 seconds, iViewer will show a popup message indicating the intermittent connect issue (only if debug mode is enabled in Project Properties)
If no Heartbeat Rx message is detected within 15 seconds, it will close the connection and attempt to reconnect.
If no heartbeat mode is selected, 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.

Each system can specify a macro to be sent every time the system is successfully connected to. This allows you to perform a macro of commands upon startup.
If no startup macro is required, simply select 'None' from the drop down list.

In GUI Designer, you can configure an external system to pass the data to send to a Javascript handler instead of directly sending it itself. Your script can massage the data any way it needs to (for example, transform the data in an encapsulated binary packet, add header and checksum, etc). While you should use this feature sparingly for performance reasons (going through Javascript to send several tens messages per second could greatly degrade performance), it can be a very useful feature in some cases.

For more details see the scripting documentation.