1. Check whether Windows sees a new USB device
Open Device Manager and watch the Ports and USB sections while reconnecting the machine. A USB-to-serial controller may appear under a chipset name rather than the laser brand.
2. Identify the serial bridge
Low-cost GRBL controllers commonly use bridges such as CH340/CH341. In the SC LABS physical workflow, the missing path ended with Windows recognising USB-SERIAL CH340 (COM4).
3. Confirm the COM port
The engraving application cannot connect to a port Windows has not created. Record the current COM number because it can change after driver or USB-port changes.
4. Match the controller baud rate
For the tested GRBL controller the working serial setting was 115200 baud. A wrong baud rate can look like a dead controller even though USB enumeration is correct.
5. Ask the controller, not the UI
A useful connection proof is a real controller response. The tested machine returned GRBL 1.1f and an Idle state. That moved the diagnosis from “USB problem” to “controller reachable; configure the job”.
6. Configure LaserGRBL only after the lower layers pass
Select the verified COM port and baud rate, connect, then inspect controller state before sending a job. Keep motion and power tests bounded so a configuration mistake does not become a damaged workpiece.
7. Separate artwork from connectivity
Image resolution, engraving direction, speed, power and material setup are job questions. They should be tuned after the serial path is stable. In the physical canvas workflow, the artwork was prepared at 4096×4096 for a layered painted canvas; that preparation could not help until the USB/serial path was fixed.
Reusable USB-laser playbook
- Reconnect and observe Device Manager.
- Identify the USB-serial bridge.
- Restore the driver path if the serial port is missing.
- Record the COM port.
- Connect at the expected baud rate.
- Verify a real GRBL banner/status response.
- Only then configure LaserGRBL and the engraving job.
- Record the known-good identity/settings for next time.
Stop conditions
Stop the generic playbook if Windows repeatedly disconnects the device, the controller never responds at known-good settings, the machine reports electrical faults, motion behaves unexpectedly or the hardware identity differs from the tested class.