Our existing teaching FR5 sometimes answers the workshop laptop's ping while its documented read-only availability check times out. Another laptop has worked. Network details from that success were not recorded. What should I compare before changing anything on the controller?
Compare the actual destination and network path used by each laptop. Record adapter, address, subnet and selected route, along with the read request and its result. A successful ping does not establish that the requested service answered.
Was the successful laptop on the same cable and network connection? The phrase another laptop worked can hide a different route as well as a different computer.
Our support laptop once worked only at the maintenance desk because that was where it used a different adapter. I would write down the physical connection before comparing the software.
Noah, did the adapter difference explain the failure, or was it just the first useful difference you found? I keep seeing familiar clues become the answer too quickly.
The successful laptop used the same bench socket, but an external adapter. Our workshop laptop uses its built-in port. Both also have wireless enabled. We have not captured which route each process selected.
Have IT capture that selection without guessing from the cable plugged in. Also compare the destination used by the script with the address you pinged; those may come from different configuration sources.
And preserve its current setup before somebody helpfully updates it. Not saying never update; just get the comparison first, including the SDK and the application configuration.
Sofia, our IT team wanted updates first. We agreed to capture the working setup and then do their planned changes. It did not need to become an argument about freezing it forever.
The second laptop is available. IT has captured both setups. The script destination matches the ping address on each; selected routes and service access are being checked next. SDK versions differ, with copies retained for comparison.
Dinesh's distinction is useful. Keep the documented method and installed version with the error. Do not alter its arguments just to make the newer package accept the call.
Who will keep the final working connection instructions at the bench? That was missing after our adapter problem, and the next person repeated the same guess.
The call reaches a timeout, not a local argument error. I will maintain the bench instructions with IT. Their route comparison found no unintended path in the captured attempts, but service access is still unresolved.
The second laptop returned the expected identity in the paired check; ours timed out. Same recorded destination. IT is comparing the service connection and local policy, while software reviews the version difference. Controller settings unchanged.
Keep those two comparisons separate in the notes. You now have a repeatable difference to investigate, but neither the SDK version nor a local policy should be named as the cause before its effect is established.