@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.

I'm running RepRap firmware 3.4.5, built by TeamGloomy, on my 3D printer with a BTT SKR 2 board. The board is connected to my Linux PC via USB.

I noticed that, when printing, the part cooling fan would turn on and off significantly earlier than needed. In extreme cases it may spin up and then spin down before a small bridge even starts printing. The fan would always turn off completely while a few last paths of a print are still printing. This happens regardless of the software I'm using: Cura, Printrun, Octoprint behave the same.

I suspect this is related to command queueing, but the documentation is pretty confusing. Emphasis is mine:

When commands are executed from a job file or a macro, RepRapFirmware stores G0, G1, G2 and G3 movement commands in a 'move queue'

Ok, the queue is only used when printing from a file on an SD card...

Some non-movement commands are also queued when executed from a job file or a macro, in a 'deferred command queue'. This operates in parallel to the 'move queue', and together the two queues operate as a single logical queue, and generally can be considered as one queue. M3, M4, M5, M42, M104, M106, M107, M117, M140, M141, M144, M280, M300 and M568 commands are all queued.

Movement and control commands go into different queues but those are synced...

As soon as one of these commands is received it is acknowledged and stored locally in the queue. If the queue is full, then the acknowledgement is delayed until space for storage in the queue is available.

Wait, what? There is no point to acknowledge to an SD card. So this paragraph clearly talks about serial communication, which is not "a job file or a macro".

I suspect this confusion is also present in the code. 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.

I wanted to file a bug report, but the Github issue tracker politely directed me here. Hopefully I'm posting in the right forum. Hopefully moderators can move this thread if I'm not.