As I mention in the previous post the data stream for grbl has codes to turn the laser off and on as well as move the parts around. If the parts are not moving and the laser is on, it more than likely it has an interrupted data stream to the laser.
It could simply be that the grbl board can’t handle massive data stream. It can only queue up a few grbl instructions in it’s command buffer. If the data to turn off the laser doesn’t make it, the laser stays on.
It would seem to add up since it does it on two different machines with images, which is what generates the large data streams along with it’s not the same place that fails.
Wish I had a magic pill, but don’t have a clue about how to fix it… it’s the processor/software (controllers) as far as I know. Don’t know that much about USB, seems to change weekly…