I'm writing a plugin that is a scanner of sorts. It takes a picture, analyzes the picture, moves the machine, and repeats. This is only intended for when the machine is not printing. This can't be a gcode program because the movement and stopping condition are dependent on the image analysis.
Currently I have it so it starts from a trigger that's exposed by a flask blueprint. It queues motion and then G4 and then a 'special' M117 command. The M117 command is picked up with a gcode sending hook, based on the assumption that the M117 won't be sent until the G4 returns 'ok', meaning all the previous commands are complete.
Within the gcode hook, it does its work, taking a picture, doing the analysis, queuing the next movement, and then releasing control, waiting to be triggered again by the 'special' M117 command. It has a state machine to track its progress within the scan.
I have a simple prototype that works, but I am wondering about the advisory to not perform any long-running operations within the gcode hooks, or it would stall the send loop. I can understand how stalling during a print job could easily degrade print performance. If I am not printing, but just using the machine as a Python-driven motion platform, do I need to worry about stalling the send loop? Is there a risk that the server might freak out and cause other bad things to happen if the loop is stalled too long?
And if so, what is a better alternative? I could imagine a separate process that sends and receives messages, so the hook just notifies the other process and does not block the send loop. The other process gets the notification and then does its work asynchronously and then somehow inserts gcode back into the queue. I have avoided multiprocessing in Python so I don't exactly know how to do this, but I could figure it out if it is the proper way.
So the question is, how bad is it to block the send loop? And if it is important not to block the queue, what is the best alternative?