Topics created by snake

@dc42 said in M106 is executed out of order when printing over USB:

My guess is, when printing over serial, movement commands are queued, but control commands are not. This causes them to be executed ahead of the movement by the size of the movement queue.

Correct. I have corrected the documentation.

Thank you very much for updating documentation. Now it matches the behavior I'm observing exactly.

However this raises a follow up question: is there any workaround besides putting a gcode file on the SD card? The inconsistent queueing is detrimental to printing bridges, which in my experience always require high airflow to avoid sagging. This puts print-by-wire at a significant disadvanage.

My setup is pretty rudimentary. I don't have an LCD, there is only one SD slot which is occupied by an SD card holding RepRap configuration, and the only way to connect to the printer is USB. My only option seems to be using M28 and friends, but 1) I'm yet to make this work due to issues in Octoprint (it fails to recognize the success response from RepRap's M21), and 2) the general consensus is that M28 is inherently very slow anyway.