Two controllers can share the visible address prefix 130.130.130.x and still remain unreachable if their subnet masks differ, the Wi-Fi and wired ports belong to different routed segments, or the laptop selects the wrong interface. The observed behavior isolates the fault to network path selection or segmentation: Wi-Fi reaches 130.130.130.1, while the wired connection reaches 130.130.130.42.
Observed Communication Paths
| Laptop path | Address | Controller visible in RSLinx | Controller not visible |
|---|---|---|---|
| Wi-Fi | 130.130.130.12 |
Line controller at 130.130.130.1
|
Sander controller at 130.130.130.42
|
| Wired through the switch | 130.130.130.13 |
Sander controller at 130.130.130.42
|
Line controller at 130.130.130.1
|
The controller originally addressed as 192.168.1.142 was changed to 130.130.130.42. That change aligns the visible address prefix but does not prove that both controllers occupy the same IP subnet or Layer 2 broadcast domain.
Most Likely Decision Points
First verify whether Wi-Fi and the switch ports are LAN interfaces in the same network. The available evidence supports a specific hypothesis: the router or switch assembly may assign different networks to its wired LAN and Wi-Fi or WAN sides. A plain unmanaged switch does not translate between such networks, while a router or access point can separate them.
Also treat the laptop's two active adapters as a diagnostic variable. Assigning both adapters addresses in the same apparent subnet can create competing routes. The immediate loss of visibility to 130.130.130.1 when Ethernet connects is consistent with interface selection, but it does not by itself prove that adapter priority is the root cause.
Isolation Procedure
- Record the IP address, subnet mask, and default gateway from both controllers, both laptop adapters, and the Wi-Fi/router LAN configuration. Do not decide that the devices share a subnet from the first three address octets alone.
- Disable the laptop's wired adapter and test direct IP reachability to
130.130.130.1and130.130.130.42. Record which destination succeeds without relying only on the RSLinx browse display. - Disable Wi-Fi, enable only the wired adapter, and repeat the same two direct reachability tests. This separates physical switching and routing results from dual-adapter route selection.
- Inspect the device joining Wi-Fi to the wired network. Confirm whether the connected ports are LAN, WAN, or isolated Wi-Fi segments and whether a route exists between the controller networks.
- After correcting the subnet, routing, or port-role mismatch, repeat the test with one laptop adapter active. Then verify that RSLinx can reach both controller IP addresses before configuring controller-to-controller data exchange.
Verification and Configuration Boundary
The network is not verified until one interface can reach both 130.130.130.1 and 130.130.130.42. If each address remains reachable only through a different laptop adapter, the controllers are still separated by routing, port roles, VLAN-like isolation, or inconsistent subnet settings despite their matching address prefix.
Do not begin controller messaging configuration until bidirectional network reachability is established. The evidence does not provide subnet masks, gateways, switch/router model, controller Ethernet-module details, or the intended Logix messaging method, so no exact route, module path, or instruction configuration can be specified safely.
FAQ
Why does RSLinx see 130.130.130.1 on Wi-Fi but 130.130.130.42 on Ethernet?
The two adapters are reaching different network paths, or the laptop selects the wired route when Ethernet connects. Test each adapter separately and compare direct reachability to both addresses.
Are 130.130.130.1 and 130.130.130.42 automatically on the same subnet?
No. Their subnet masks must be examined before that conclusion is valid, and router, WAN, or isolated Wi-Fi boundaries can still separate the devices.
What should I verify before configuring Logix controller messaging?
Using one active laptop interface, verify direct reachability to both 130.130.130.1 and 130.130.130.42. Then confirm the controllers' masks, gateways, and the LAN/WAN roles of the intervening network device.