Our workshop laptop sometimes pings Fairino FR5, but the documented read-only check for controller identity retrieval times out.
A second laptop has worked, though its network notes are incomplete.
We're in a workshop commissioning bench, with a fixture plate as a reference.
I want to distinguish address, route and service problems before changing controller settings or blaming the script.
Compare the recorded controller endpoint with the route each laptop selects for it, using sanitized details that omit unrelated network addresses. Do those routes differ?
Have the network owner assess and correct the identified route difference, then repeat the documented read-only check. That should settle the connection issue.
@JonasChen1155 You're right about my prediction. The repeat check tests the routing hypothesis, with connection-stage failures kept separate from subsequent service or application responses.
Ping gives limited information about reachability under its own handling rules. Its success doesn't verify the SDK service, and its failure doesn't establish controller unavailability.
I've identified a specific routing difference between the laptops. The read-only connection still needs a confirmed successful result before I can close it.