Fix Kogna Connection Loss After a Static IP Change

The board connects while the PC uses automatic IPv4 configuration, then disappears when the PC is changed to 192.168.1.200. The static PC address changes the Layer 3 path; the board must also have a unique address that falls within the same subnet under the selected subnet mask. A proposed board address is 192.168.1.201, provided that address is unused.

Address plan and prerequisites

Before anything else, confirm the device identity. The supplied information uses both “Konga” and “Kogna.” Check the label or configuration utility and use the exact product selection shown there; the naming difference does not change the IPv4 procedure.

The last octet alone does not prove that two addresses share a subnet. The configured subnet mask makes that decision. Read the mask used by the working automatic configuration or obtain it from the network address plan, then apply the same mask to both endpoints. A default gateway is not the path between two devices that classify each other as local; the gateway matters only when traffic must leave the local subnet.

1. Record the PC address, subnet mask, gateway, and board address while automatic configuration still works.
2. Check that 192.168.1.200 and 192.168.1.201 are not already assigned to other devices.
3. Identify the physical Ethernet adapter connected to the board or its switch.

Do not move on until the working configuration is recorded and both proposed addresses are unique.

Temporary restoration of board access

The board cannot be readdressed through a path that the PC can no longer reach. Restore the last working PC mode before changing the board.

1. Return the connected Ethernet adapter to automatic IPv4 configuration.
2. Reconnect to the board using the same application and cabling that worked previously.
3. Open the board’s network configuration and record its current address mode, IPv4 address, and subnet mask.
4. Confirm that the application is communicating with the intended physical board before writing any setting.

Automatic operation proves that the Ethernet link and application can work together, but it does not prove that 192.168.1.200 is compatible with the board’s current subnet. Changing only the PC can place the endpoints in different logical networks even though the cable and link indicators remain normal.

Do not move on until the board is accessible again and its current network values have been captured.

Board static IPv4 assignment

Assign the board a fixed address before placing the PC permanently at its required address. The proposed pair keeps the endpoints distinct: PC 192.168.1.200 and board 192.168.1.201.

1. Verify once more that 192.168.1.201 is unused. An address conflict can produce intermittent communication, unexpected disconnects, or traffic reaching the wrong device.
2. Select the board’s manual or static IPv4 mode in its configuration interface.
3. Enter 192.168.1.201 as the board address.
4. Enter the subnet mask selected from the working configuration or approved network plan.
5. Apply or save the configuration. Expect the current session to drop if the address changes immediately.
6. If the board stores network settings persistently, use the interface’s normal commit operation before removing power.

Do not copy a gateway value merely to make the fields look complete. For direct local communication, the decisive values are the two unique IPv4 addresses and the matching subnet definition. If the board requires a gateway field, enter the value defined by the network plan.

Do not move on until the board reports 192.168.1.201 or the saved configuration can be read back.

PC static IPv4 assignment

Configure only the adapter that physically carries board traffic. Editing a wireless, virtual, or disconnected adapter leaves the real Ethernet path unchanged.

1. Open the IPv4 properties of the active Ethernet adapter.
2. Select manual addressing and enter 192.168.1.200.
3. Enter the same subnet mask used for the board.
4. Enter gateway and name-server values only when required by the wider network design; they are not needed to select a directly connected local board.
5. Apply the settings, then read the adapter status back to confirm that 192.168.1.200 is active.

Check for another active adapter with an overlapping route to the same address range. Wireless connections, virtual-machine adapters, VPN clients, and secondary Ethernet ports can cause the operating system to choose an unintended interface. Temporarily disabling an unrelated overlapping path is a valid diagnostic step, but preserve its original settings so it can be restored.

Do not move on until the connected adapter shows 192.168.1.200 with the intended subnet mask.

Layered connection checks

Test the path below the control application first. Application discovery can depend on broadcast traffic, adapter selection, or firewall policy, while direct communication uses the board’s assigned address.

1. Confirm the physical link on both ends.
2. Run the operating system’s normal reachability test against 192.168.1.201.
3. If that fails, inspect whether the PC resolves a hardware address for 192.168.1.201. Failure at this stage points to link, subnet, duplicate-address, or board-configuration problems rather than application logic.
4. If direct reachability succeeds, configure the control application to target 192.168.1.201 explicitly when it provides a manual-address option.
5. If manual targeting works but discovery does not, inspect application adapter binding and firewall policy without changing the endpoint addresses again.

Do not move on until the PC reaches 192.168.1.201 independently of automatic discovery.

End-to-end verification

1. Connect the application to the board at 192.168.1.201.
2. Confirm that the application identifies the intended board and can perform the required control operation.
3. Disconnect and reconnect the application to prove that the address is repeatable.
4. Restart or power-cycle the board through the normal commissioning procedure, then verify that it returns at 192.168.1.201.
5. Confirm that the PC remains at 192.168.1.200 and that communication works without returning either endpoint to automatic configuration.

FAQ