Our cell is unavailable, so I'm working offline on inspection result parsing for Universal Robots UR5e in a fixture inspection station, with an inspection block as a reference.
The existing SDK mock returns true from every method.
The screen looks happy, but that doesn't catch interface mistakes.
I want a useful software substitute without claiming it simulates the physical robot.
Do you've captured success and error responses tied to the documentation for the SDK your screen uses? Those would give the substitute concrete contracts to follow.
Use a small substitute implementing only your required methods, matching the saved response contracts and rejecting unexpected calls. That should keep the run contained offline.
Rejecting unknown mock methods doesn't establish that the application stays offline. Another startup path could still create the real controller client.
@RobinBell0686 My containment claim was too broad. Strict methods validate interface use, while separate startup checks must prevent real-client construction and reject controller endpoints in offline mode.
@JamieBennett0730 Yes, treat that as an explicit offline failure. It identifies an unsupported method or unwanted application call and should never trigger controller access.
My substitute accepted arbitrary method names. A typo passed every offline run. The fake was exceptionally supportive and entirely useless for that mistake.
I've settled what this mock is for: checking our documented interface with explicit success and error cases.
I'll count it ready only when those checks pass and the offline run attempts no controller connection.