What is the Pair Connection function

Pair Connection is a function available in selected ICP DAS Ethernet I/O modules that allows signals between two devices to be linked directly over Ethernet. In practice, this means it is possible to create a relationship such as:

  • DI to DO
  • AI to AO

What matters most, however, is what Pair Connection is not. It is not a logic controller, it is not an event-driven mechanism, and it is not a PLC replacement. The function works as cyclic I/O state mapping via Modbus TCP.

In simplified form, it works like this:

  • one module makes the state of its inputs available,
  • the second module reads that state over the network,
  • and writes it to its own outputs.

If the remote input changes to ON, the corresponding local output will be set to ON during the next polling cycle. When the input returns to OFF, the output will also return to OFF. Pair Connection should therefore be treated as distributed input-to-output state mapping rather than control logic.

What operating modes are available

Depending on the series and model, Pair Connection may operate in two modes:

  • Push – local inputs are transferred to remote outputs
  • Pull – the local module reads remote inputs and maps them to its own outputs

From a project perspective, both modes lead to a similar process effect, but they differ in which side the communication relationship is built on.

In practice, for a system such as:

  • module A – digital input
  • module B – digital or relay output

Pair Connection can be established either from the signal source side or from the receiving side.

Where Pair Connection is best suited

This function works best wherever a simple dependency is needed:

input state = output state

Typical applications include:

  • mapping the state of a limit switch to a remote output
  • transferring an alarm signal to another cabinet
  • remote relay activation based on an auxiliary contact
  • simple binary control without a PLC in between

The greatest advantage here is simplicity. There is no need to program a controller, create intermediate logic, or maintain a separate master device. In simple module-to-module applications, this provides fast and predictable commissioning.

What Pair Connection does not perform

This limitation should be made clear at the very beginning of the project. Pair Connection does not natively perform:

  • sequential logic
  • toggle functionality with each press
  • pulse generation with a defined duration
  • delayed activation or deactivation
  • AND, OR, XOR conditions
  • flip-flops and interlocks
  • arbitration of multiple signal sources

This is not a PLC runtime. If the application requires event interpretation, logic conditions, or time-based dependencies, the Pair Connection function alone will not be sufficient.

Configuration parameters that matter

When configuring Pair Connection, the following parameters are the most important:

  • Connection Timeout – waiting time to establish the connection
  • Reconnect Interval – interval between successive connection attempts
  • Communication Timeout – waiting time for a response from the remote device
  • Scan Time – remote device polling period
  • IP Address of the Remote Device – IP address of the remote module
  • Modbus TCP Port – Modbus TCP communication port
  • Modbus ID – identifier of the remote device
  • Local DO Base Address / Local AO Base Address – starting point of the local output map
  • Remote DI Base Address / Remote AI Base Address – starting point of the remote input map
  • I/O Count – number of mapped channels

These parameters define not only the connection itself, but also the technological meaning of the entire relationship.

Pair Connection does not map signals by names, but by channel addresses. This means that setting, for example:

Local DO Base Address = 0

Remote DI Base Address = 0

I/O Count = 2

creates the following relationship:

DO0 ← DI0

DO1 ← DI1

If the base address or the number of channels is set incorrectly, communication may work correctly, but the wrong I/O points will be mapped.

What configuration looks like in practice

For the DI to DO variant, a typical configuration looks as follows:

  • assign the modules correct IP addresses
  • log in to the web interface of the module configuring the relationship
  • go to the Pair Connection section
  • select the appropriate operating mode, e.g. Remote DI to Local DO
  • enter the remote device IP address, port, and Modbus ID
  • set the timeouts and Scan Time
  • set the input and output base addresses
  • define the number of mapped channels
  • save the configuration
  • perform an operational test on the actual I/O points

At the commissioning stage, it is not enough to verify that the connection is active. It must also be confirmed that the correct input controls the correct output.

Response time and polling nature

The most important characteristic of Pair Connection from an automation perspective is very simple: it is a cyclic mechanism.

This means that the system response depends on:

  • Scan Time
  • network response time
  • Ethernet connection quality
  • communication load
  • output write time after the input is read

In practice, the signal is not transferred “instantly”, but only during the next polling cycle. That is why Pair Connection is suitable for simple state mirroring, but it should not be treated as:

  • a fast deterministic bus
  • a safety system with low latency
  • a tool for precise time-based logic
  • a solution for very short pulses

This is one of the most important things to consider before selecting the devices.

Monostable pulse versus bistable signal

In practical project work, this distinction is of key importance.

Monostable signal

If the signal source is a short pulse, there is a risk that the second module will not manage to read it between polling cycles. The shorter the pulse and the longer the Scan Time, the greater the probability of missing the event.

In such a system, a situation may occur in which the input actually changed state, but the output never reflected it.

Bistable signal

With a bistable switch, the problem looks different. The signal is not a short pulse, but a sustained state:

  • the input changes to ON
  • it remains ON for a longer time
  • the remote module reads the state in the next cycle
  • the output changes to ON
  • when the input returns to OFF, the output also returns to OFF

This is exactly why, in an architecture without a PLC and without intermediate logic, a bistable signal is a much more reliable solution than a monostable push button.

DI Latch and DI Counter – what they are used for

In selected modules, additional helper functions are also available for digital inputs.

DI Latch

DI Latch works like an event latch. After detecting a change in the input state, the module remembers that fact and maintains the information until it is cleared manually.

In practice, this means:

  • a short pulse can be registered
  • the information about the change does not disappear immediately
  • the latched state must later be reset

DI Counter

Counter is a pulse counter on the digital input. It counts successive events and stores the result in a register.

This solution makes sense when the following are important:

  • the number of pulses
  • the presence of short events
  • a measurement or diagnostic function

What is important from the project perspective

DI Latch and DI Counter:

  • help detect short events
  • do not turn Pair Connection into event-driven logic
  • do not independently control the output
  • do not replace a PLC or a master application

If the system has no higher-level layer, these functions remain auxiliary tools rather than a complete control mechanism.

Input filtering and contact bounce

With signals from switches and mechanical contacts, contact bounce must be taken into account, meaning fast, short ON/OFF transitions during switching.

That is why DI Low-Pass Filter plays an important practical role. Its purpose is:

  • input state stabilization
  • limiting false transitions
  • improving signal quality from mechanical elements

From a project perspective, this means two things:

  • for mechanical contacts, the filter is usually recommended
  • filtering simultaneously makes it more difficult to detect very short pulses

In other words, the filter helps with state control, but it does not solve the problem of very short pulses in a system based only on Pair Connection.

Safe Value, watchdog, and behavior in the event of communication failure

In industrial applications, what happens to the output after communication is lost is very important.

That is why, when configuring Pair Connection, attention must be paid to:

  • Power-on Value
  • Safe Value
  • watchdog mechanisms
  • the output response after loss of the communication relationship

From the process perspective, it should be clearly defined:

  • whether the output should go to OFF after a failure
  • whether it should be forced to ON
  • whether it should assume another defined safe state

For relay outputs controlling a real object, this parameter cannot be left to chance.

One signal for two output modules

This issue often appears in practice. If one input signal is to control two output modules in different IP locations, Pair Connection should not be treated as a broadcast mechanism.

In practice, what must be established is:

two independent Pair Connection relationships

Most often, this is done in such a way that both receiving modules read the same signal from a common source module. The process effect is then correct, but technically these are two separate connections.

Conclusions for applications with tET-PD2R1

In applications where a digital input on one module is to control a relay output on another module without a PLC in between, Pair Connection is a valid solution provided that the signal has the character of a maintained state rather than a very short pulse.

The most important conclusions are as follows:

  • for a bistable signal, Pair Connection works well
  • for a short monostable signal, there is no guarantee of reliable detection
  • DI Latch and Counter help detect an event, but they do not independently control the relay
  • for mechanical contacts, it is worth considering an input filter
  • Safe Value should be set consciously, in line with process requirements

Summary

Pair Connection is a function for simple, direct I/O state mapping over Ethernet rather than a tool for implementing complex control logic.

It works best where the following relationship is needed:

  • one input
  • one output
  • simple ON/OFF state
  • no PLC in between

This function should not, however, be treated as a solution for:

  • short pulses
  • sequential logic
  • time-based functions
  • toggle and flip-flops
  • complex conditional control

In simple module-to-module applications, Pair Connection is a useful and predictable function. In more complex systems, it remains only a communication layer for signal mapping, and the process logic must be implemented separately.