Distributed I/O only works because two kinds of communication module play opposite roles. One sits with the controller and reaches out to gather data; the other sits with the remote I/O and answers when it is called. Get these roles straight and a distributed I/O drawing reads clearly; confuse them and commissioning turns into guesswork. This guide explains the scanner and the adapter, why they are described as master and slave or originator and target, how they pair up over EtherNet/IP or Profinet, and what connections and the requested packet interval actually mean when you set up a node.
Scanner vs Adapter in one line: A scanner is the communication module on the controller side that initiates communication - it polls remote I/O nodes, so it is the master or originator of the connection. An adapter is the communication module on the remote I/O side that responds - it presents its rack of I/O to the scanner and returns data when polled, making it the slave or target. The scanner establishes a connection to each adapter, and that connection carries input and output data at a configured update rate. One scanner typically talks to many adapters.
A scanner is the active party in distributed I/O. It lives with or near the controller and its job is to reach out across the network to every remote node the controller owns, open a connection to each, and then continuously exchange data - reading the inputs those nodes gathered and writing the outputs the controller wants applied. Because it starts the conversation and drives it, the scanner is called the master, and in EtherNet/IP terms the originator: the device that originates the connection. A single scanner usually manages many remote nodes, cycling data with all of them so the controller has a current picture of the whole distributed system.
The scanner function may be a dedicated communication module in the controller's rack, or it may be built into the controller or its network port. Either way, its configuration is where the topology is defined: the engineer tells the scanner which adapters exist, at what addresses, what each node's I/O looks like, and how often to exchange data with each. The scanner holds the map of the distributed system and does the work of keeping every node's data current in the controller's memory.
Because the scanner initiates and monitors every connection, it is also the natural place to detect when a remote node has gone missing. If an adapter stops responding, the scanner sees the connection time out and flags that node as faulted, which the controller program and SCADA can act on. In that sense the scanner is not just a data mover but the component that knows the health of the entire distributed I/O network from the controller's point of view.
An adapter is the passive counterpart. It sits in the remote I/O rack, out in the field or on a machine, and its role is to represent that rack of I/O modules on the network so a scanner can reach it. It does not initiate anything; it waits to be found and connected to, answers the scanner's requests, hands over the current input data from the modules behind it, and applies the output data the scanner sends. This responder role is why it is called the slave, or in EtherNet/IP terms the target: the device the connection is targeted at.
From the scanner's perspective, the adapter is the doorway to a whole set of I/O points. Behind a single adapter can sit a rack of many modules - analog inputs, discrete outputs, and so on - and the adapter aggregates all of them into the data the scanner exchanges. That is exactly what makes distributed I/O efficient: the controller opens one connection to the adapter and gets everything in that remote rack, rather than dealing with each module individually across the network. The adapter also typically reports the presence and health of the modules behind it, so the scanner learns not just the data but whether the remote rack is intact.
It is worth noting that the same physical hardware can sometimes play either role depending on configuration, and that a device can be a scanner for some connections while being reachable as a target for others in more complex architectures. But the mental model that keeps commissioning straight is the plain one: the scanner reaches out and polls, the adapter sits still and answers, and every distributed I/O connection is one scanner talking to one adapter.
To bring a distributed node online, the scanner and adapter have to be paired in configuration. The scanner is told the adapter's network address and given a description of the remote rack - which modules are present and in what slots - so it knows what data to expect and how to map it into the controller. Each connection is set with a requested packet interval, or RPI: the rate at which the scanner and adapter exchange their data. A faster RPI gives more current data at the cost of more network traffic, so it is tuned to how quickly the signals on that node actually change - fast for a node full of control loops, slower for one reading tank levels.
The same master/responder pattern appears on both EtherNet/IP and Profinet, with different vocabulary. EtherNet/IP speaks of scanners and adapters, originators and targets. Profinet speaks of IO controllers and IO devices, which map to the same roles: the IO controller is the polling master like a scanner, and the IO device is the responding remote rack like an adapter. Recognizing that the terminology differs but the roles are identical lets an engineer move between the two networks without relearning the concept.
Reading a distributed I/O topology, then, comes down to identifying which device originates and which responds, and following the connections between them. During commissioning this is exactly the frame that resolves problems: a node that will not come online is a scanner-to-adapter connection that is not establishing, so you check the address, the module configuration match, and the network path between the two. When that distributed I/O feeds a cloud SCADA platform such as Merobix, the scanner's view of each connection's health becomes valuable telemetry - the platform can surface which remote adapters are online and which have dropped, so an operator watching a spread-out field sees node connectivity the same way the scanner sees it, from a single screen rather than by walking each panel.
The scanner is the master. It initiates and drives communication - it opens connections to remote I/O nodes and polls them for data - so in EtherNet/IP terms it is the originator. The adapter on the remote rack is the slave or target: it waits to be connected to and responds. A quick way to remember it is that the scanner reaches out and the adapter answers.
Profinet uses different words for the same roles. The IO controller is the master that polls, equivalent to a scanner or originator. The IO device is the remote rack that responds, equivalent to an adapter or target. The concept is identical - one device initiates and drives the data exchange, the other presents its I/O and answers - so understanding scanner and adapter carries directly over to Profinet.
RPI is the requested packet interval - how often the scanner and adapter exchange their input and output data over the connection. A shorter RPI means more up-to-date data but more network traffic, so you tune it to how fast the signals on that node change. Fast-moving control loops warrant a short RPI, while a node reading slow values like tank levels can use a longer one to save bandwidth.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.