The CPU Sees the IP but Not the Device: PROFINET Station Naming vs Modbus Polling, Done Right

PROFINET and Modbus TCP can share standard Ethernet infrastructure, yet they identify devices and exchange process data in very different ways. A successful ping proves only basic IP reachability. It does not prove that a PROFINET application relationship has formed or that a Modbus register map is being polled correctly.

This commissioning workflow separates Ethernet reachability from protocol identity, configuration, cyclic data exchange, and controller mapping on Phoenix Contact and Bachmann-based systems.

Two protocols, one cable

Modbus TCP uses a client/server request-response model. The client requests coils, discrete inputs, input registers, or holding registers with defined function codes, and the server returns a response or exception. Process data changes at the controller only when the application issues successful requests at the configured rate.

PROFINET IO uses an IO controller and IO devices. After discovery, parameterization, and connection establishment, the controller and device exchange cyclic process data according to the engineered update relationship. A device does not simply publish usable cyclic data before that relationship exists.

Both protocols can continue communicating with healthy peers when one device fails, but the actual effect depends on the controller program, connection resources, timeout settings, network design, and failure handling.

PROFINET: name it, then connect it

A PROFINET IO device is commonly assigned a station name using the Discovery and Configuration Protocol, or DCP. The IO controller uses the engineered station name to identify the intended device and coordinate its network configuration.

• Assign a unique, standards-compliant station name.
• Confirm the detected MAC address matches the physical device.
• Compare the online station name with the name in the engineering project.
• Verify the IP address and subnet settings assigned by the approved configuration.
• Check for duplicate names and addresses before downloading changes.

Copying only the previous IP address may not restore an IO device when the station name or device identity is wrong. Automatic replacement by topology or controller assignment is possible in some systems, but it must be engineered, supported, and tested rather than assumed.

Modbus TCP: poll the right data

For a direct Modbus TCP server, the IP address and TCP port identify the endpoint, while the register type, offset convention, length, data type, and byte or word order determine whether the returned value is meaningful. The Unit Identifier is especially important when a TCP-to-serial gateway routes requests to downstream Modbus devices; some direct TCP devices ignore it, while others use it in a vendor-specific way.

• Confirm the server IP address, TCP port, and connection limit.
• Match the function code to the correct data table.
• Resolve zero-based versus one-based register notation.
• Confirm signed, unsigned, floating-point, and scaled data types.
• Verify byte and word order with a known live value.
• Set polling rates, timeouts, and retries so one failed device does not overload the controller or network.

A frozen display can result from a timeout, stale-value handling, or application logic that retains the last good value. Monitor quality and data age, not only the numeric tag.

RT versus IRT: use the performance class the application needs

PROFINET RT exchanges real-time Ethernet frames without relying on TCP for cyclic IO and suits many factory-automation applications. PROFINET IRT adds scheduled communication and tighter synchronization for demanding motion and timing use cases.

IRT requires compatible controllers, devices, switches or integrated ports, topology, synchronization, and engineering support. Select RT or IRT from the machine’s timing and jitter requirements, not from a blanket preference. In Modbus TCP, response time depends on scan logic, request scheduling, server capacity, network latency, timeouts, and the number and size of transactions.

GSDML, firmware, and module identity

A correct station name cannot compensate for a mismatched device description or module layout.

• Load the GSDML file appropriate to the exact device and supported revision.
• Compare configured slots and subslots with the installed hardware.
• Check firmware compatibility and device-specific parameters.
• Verify input and output lengths and controller tag mapping.
• Review the controller and device diagnostics before replacing hardware.

On Bachmann systems, confirm the communication capabilities of the exact CPU and software package. A catalog reference such as the Bachmann MPC240 processor module identifies the hardware family, but supported protocol roles and options still need to be verified from its project documentation.

Check the Ethernet infrastructure

A managed or industrial switch can help isolate link flaps, CRC errors, congestion, duplicate addressing, and topology changes. The Bachmann SWI205 Ethernet switch is a relevant catalog example, but its suitability for PROFINET RT or IRT must be confirmed from the exact specifications and engineered performance class.

Do not confuse Ethernet-based PROFINET components with RS-485 PROFIBUS hardware. For example, the Phoenix Contact 2708232 D-SUB bus connector belongs in a serial fieldbus context, not on a PROFINET Ethernet link.

Why faults can look deceptively quiet

Modbus TCP may keep a session open while individual requests fail, return exceptions, or map data incorrectly. A byte-order mistake can produce plausible but wrong values. PROFINET usually exposes missing-device, module, submodule, and channel diagnostics, but a green link indicator still proves only physical connectivity.

• Watch communication status, data quality, update age, and diagnostic counters.
• Force or observe a safe, known process change and confirm it reaches the correct controller tag.
• Correlate intermittent faults with topology changes, motor starts, controller load, and network utilization.
• Capture evidence before cycling power or reassigning a name.

Field procedure: commissioning either protocol cleanly

1. Verify cable, connector, link, switch port, VLAN, and IP-subnet health.
2. For PROFINET, discover the device with DCP and assign the engineered station name.
3. Confirm the correct GSDML, hardware identity, firmware, slot/subslot layout, and IO lengths.
4. For IRT, verify every device and network component supports the engineered synchronization and cycle plan.
5. For Modbus TCP, confirm endpoint, function code, register reference, data type, byte order, polling interval, timeout, retry, and Unit Identifier behavior.
6. Observe live data exchange and diagnostics rather than relying on ping or a green LED.
7. Test failure behavior, stale-data handling, recovery, and reconnection under an approved procedure.
8. Record station names, addresses, MAC addresses, firmware, device-description versions, and register-map revisions in the shared asset record.

Conclusion

An IP-reachable device is not necessarily an operational PROFINET IO device or a correctly mapped Modbus server. For PROFINET, verify station naming, device identity, GSDML configuration, and the established cyclic relationship. For Modbus TCP, verify every part of the request and data interpretation. Commission from physical link to controller tag, and prove the live data path before trusting the status LED.