I thought I'd made the laptop rebuild boring: same read-only identity script, same shortcut name, copied the SDK folder from the old machine. Now an argument is rejected before the query reaches the controller.
There are also two SDK copies left from training. Their folder names tell me nothing, and the colleague who prepared them is away. I don't want to fix a harmless query by randomly changing its arguments until one library likes it. What would you compare first on the working and rebuilt laptops?
Compare the actual interpreter and imported module path from each normal launch, then the failing call's signature and the supplied arguments. Folder names and shortcut labels can match while the running code comes from somewhere else.
Keep the full error too. A screenshot cropped to 'argument' is going to send everyone guessing. No need to involve the controller while the call is failing locally.
Our teaching shortcut survived a laptop move but still pointed at the old working directory. I spent longer defending the familiar icon than checking it. Worth opening its properties before anyone rewrites a working script.
Imran, was the wrong script running, or was the right script finding files in the wrong place? Both look like 'same shortcut' to someone taking over the bench, but the handover needs the actual answer.
The script is the intended file. The rebuilt launch imports from a training folder, not the copied SDK folder. I've kept the full error and both paths. Ella's comparison found more than the folder labels did
Do not assume the copied folder is the correct supported choice merely because it matches the old laptop. Establish the controller and interface versions used in the working configuration. Otherwise you may reproduce an undocumented mismatch more consistently.
Isaac, agreed. But recording what works is still useful evidence. Chen needs the compatibility question answered before choosing, not every existing result discarded.
Jo, right script, wrong directory for a settings file in my case. We fixed the launcher and wrote down its working directory. I'm not saying Chen has that same fault; his imported path is the thing he's actually found.
Keep the old laptop available until the supported configuration is confirmed. It is the only working comparison described here, not spare storage to tidy during the rebuild.
Martin, and leave a plain description of which launcher produced the comparison, so the next tutor doesn't unknowingly use a different route and wonder why the recorded paths disagree
Lin, yes, the old result is a comparison rather than an automatic recommendation. Chen, did the two imported copies expose different signatures for the query that failed? That would connect the path difference to your actual error.
They do. The training copy has a different argument list, and the failing call matches neither its example nor its signature. The old working configuration is now identified; support is confirming applicability to this controller before I adopt it on the rebuilt machine
Ada, I'd favour a small diagnostics view over extra startup questions, because a tutor should not have to choose between similarly named SDK copies every time they need the identity check
Support has confirmed the identified working combination. Rebuilt launcher now imports that copy, and the query's local argument check passes. I haven't called the controller from it yet. Thanks Beth, keeping the whole error stopped us arguing over the screenshot wording
Who maintains that launcher when the next training package arrives? The extra copies can be legitimate teaching material, but they should not quietly become the production query's import source again.
Our lab maintainer owns the launcher and environment description. Training packages stay separately identified. Controller comparison still pending, so I have not described the rebuilt laptop as ready for the bench