My workshop laptop gets occasional ping replies from the FR5 but the documented read-only diagnostic request times out. Another laptop worked; its network notes are patchy. This is our fixture-plate maintenance station. I want evidence of the endpoint and path before anybody changes the controller or rewrites the script.
What survives from the working visit? A screenshot, the connection profile, even the actual command and target would be more useful than the word worked. Ask the person who used that laptop.
And write down which adapter your workshop laptop is using. We call a laptop connected when the cable is in, but that doesn't tell the next person where its traffic went. Address, route, target and time beside the failed check.
Robin, I agree about the record, but don't let that become a diagnosis of the adapter. Intermittent ping and a service timeout can have different explanations. Victor hasn't got a matched comparison yet.
I've found a photo of the second laptop showing a returned diagnostic value. No target or adapter details in the photo. Its owner can revisit but hasn't given me a date.
Amy, yes, I meant record it rather than change it. For Victor's next check I'd have the network person capture the selected route while he runs that same documented request. Keep the controller setup alone during this comparison.
The photo establishes less than I hoped. Ask whether the value was a fresh response or already on the screen. I am not saying it was stale, just that the distinction affects what you can compare.
Current endpoint is now in the log with the request time and loaded SDK location. Owner says the other value followed a request, but has no saved response. I won't use the photo as a complete working baseline.
That's the useful limit on it. You can still ask support whether your recorded endpoint and documented service match the controller configuration they expect, without pretending you know what the second laptop used.
Network support has our capture. Controller changes aren't proposed. They want a simultaneous record of the route and request because my first note recorded the settings before the failure, not at it.
That timing detail matters. A screenshot of settings before lunch isn't necessarily a record of the connection that failed later. I'd keep the first capture, label what it actually proves, and add the matched one rather than replacing history
Matched capture sent. The same read timed out. No interpretation back yet; the visiting laptop is still unavailable, so this hasn't become the two-machine comparison I'd hoped for.
Can the support contact give you a next review time? Otherwise you've exchanged an unexplained timeout for an unexplained wait. Keep the workshop record useful to someone other than the visiting laptop's owner.
And resist buying a third laptop in the meantime. Nothing here yet says the computer is unsuitable; the recorded path and service still need an answer.