I've inherited an FR10 diagnostic laptop which retrieves controller identity under the technician's login but times out under our maintenance login. Ping answers on both. Same laptop and cable, though there may be settings tied to the account. Before anyone changes the controller address, I'd like a comparison that catches those differences.
Capture the actual destination and SDK environment under both logins. The same desktop shortcut can start different configurations. Leave the working controller settings alone while you compare.
The shortcut names match. I haven't checked their targets, which is mildly embarrassing given how many inherited shortcuts I've complained about. I'll get both launch details from IT.
Our diagnostic laptop once took the unexpected adapter, so I'd ask IT to include the route under both accounts as well; I spent ages staring at a timeout before anyone checked that bit.
Elliot, the ping was using the address in the maintenance sheet. The script gets its destination from a settings file. Grace, route comparison is in IT's check too.
No. Technician login points to the current controller address; maintenance login reads an older copy from its own profile. IT found it in the launch log.
That gives you a concrete difference to correct. Have IT check how the supported launcher is meant to find its configuration, otherwise copying the file once could leave you with the same problem for the next account.
IT proposed one managed configuration for this bench and an explicit destination in the diagnostic output. Not applied yet. The SDK versions match; the route to the intended controller is also the same in their comparison.
Have IT account for that old destination. A timeout doesn't identify what was there, and the diagnostic should verify the returned controller identity rather than accepting any reply.
Grace, it's part of the managed bench setup in IT's proposal. Sofia and Elliot, they're checking the old address assignment; we have no successful identity reply from it and aren't treating it as a known controller.
Once the approved change is installed, repeat the documented identity check from both accounts and compare the returned identifier with the actual unit.
And try the supported launcher from a clean account during IT's check. Existing profiles sometimes hide a dependency the shared configuration was supposed to remove.
IT installed the launcher change. Both existing accounts retrieve the expected unit identity now. Imran, the clean-account check is still outstanding, so I'm leaving the handover open.
Yes, Grace, IT owns that update with the bench configuration. Clean-account check passed too. The older destination belonged to a retired bench entry, according to their inventory. We removed that obsolete local file and closed the laptop issue. Thanks Elliot for questioning where each test was actually going.
Good. Put the destination and returned identifier in the support capture instructions as well; they'll make the next report considerably easier to read.