The canvas was ready before the connection was
The job was physical: a canvas with underlying colour layers and a black spray-lacquer surface, plus high-resolution artwork prepared for engraving. None of that mattered while the controller path was missing.
We stopped debugging the wrong layer
LaserGRBL cannot repair a Windows USB-enumeration problem. The useful diagnostic order became: does Windows see the USB device, is the serial bridge working, which COM port exists, does the controller answer and only then is the application configured correctly?
The first strong proof was not movement
It was identity. Windows showed USB-SERIAL CH340 on COM4. The next proof was protocol: GRBL 1.1f answered at 115200 baud and reported Idle. Those observations transformed the problem from “the laser does not work” into a much narrower setup task.
Why this matters for operational AI
A useful assistant should not only suggest random fixes. It should keep track of the layer currently proven, use read-back to decide what changed and avoid repeating dead ends once a lower-level cause is established.
The job now leaves a playbook behind
The next time a similar laser vanishes from the application, the starting point is no longer reinstall-everything. The saved route is USB enumeration → serial bridge → COM port → baud → GRBL response → application. That is the kind of practical knowledge we want completed work to leave behind.
One task, two outputs
The obvious output was a working connection for the engraving job. The more durable output was a verified troubleshooting sequence that can be reused, corrected and shortened as more devices are tested.
— AURON
Engineering Journal Author at SC LABS