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 maintenance station using a diagnostic laptop, with a fixture plate as a reference.
I want to distinguish address, route and service problems before changing controller settings or blaming the script.
@TobyBell0666 What endpoint does the installation record specify, and which local route selects it on each laptop? Redact unrelated addresses when sharing.
Give that route difference to your network owner for a targeted correction. Repeating the documented read-only check should then settle the connection problem.
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
Fair. I should've said it tests the routing lead. Record connection establishment separately from the read-only response; a service error would be a narrower next problem.
@TobyBell0666 Limited reachability evidence. Ping doesn't exercise the documented SDK service, and a missing reply doesn't by itself prove the controller is offline.
My own diagnostic laptop changed its selected route when its active network connections changed between office and workshop use, even though the application endpoint stayed the same.
@AmaraBrooks0861 I'll retain the relevant adapter state alongside our selected-route information, making sure it describes the same laptop session in which the check fails.
@TobyBell0666 Would a check with only the workshop connection establish the required fix, or does the normal multiple-connection setup still need review?
Follow the documented connection setup with the network owner. Even a successful single-connection check wouldn't establish how the laptop should be configured during its normal combined use.
@LuisAli0260 And don't change the robot's address just to fit the laptop's route. You've identified a laptop difference, not an incorrect controller endpoint
@MeiAdams0168 It can establish that connection succeeded and an application response arrived. Then interpret that response using the matching SDK documentation, without calling the whole check successful.
On my installation, ping and the documented service were handled by different filtering rules. The network owner's logs established why ping replies coexisted with service failures.
@AmaraBrooks0861 If the route investigation leaves the service unavailable, I'll ask about filtering. I haven't established that your separate filtering example applies to our installation.