Our workshop laptop sometimes pings Fairino FR10, 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 an inspection fixture as a reference.
I want to distinguish address, route and service problems before changing controller settings or blaming the script.
@JackBennett0776 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?
@AlexAbbott0037 The recorded endpoint agrees with our script. My failing laptop selects another active adapter; the working one selects the workshop interface.
Have the network owner assess and correct the identified route difference, then repeat the documented read-only check. That should settle the connection issue.
@AlexAbbott0037 A route correction addresses the identified difference but doesn't guarantee service availability. The next check could establish connection and then fail at the application stage.
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.
@JackBennett0776 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.