"Stop Print" doesn't purge commands

[thinkyhead]

When "Stop Print" is used to stop printing from SD, if the machine is waiting inside M109 or M104 apparently the next command in the command queue (or from the SD card) is executed. In my case, this sets the extruder temp to 195 (and waits) because the next command is M109 S195.

When stopping a print, anything left hanging around in the command queue should be purged and ignored, and no more commands should be read from SD.

• Is this new behavior or an old problem?
• Is there a preferred technique to purge the command queue for cases like this?

[lavato]

Not sure if this is the same problem - if I stop a print couple of times, eventually the new print offsets about 3cm towards the X0. (Y & Z are OK)

[thinkyhead]

Hmm. It's possible for the current_position to be set with the anticipation that a move just added to the planner will definitely finish. But if moves are purged from the planner after that point, the current_position will no longer be properly synchronized to the planner position. Thus it is very important that after killing a print, if moves are purged from the planner, the current_position should be re-established from the current planner position (i.e., calculated from the current stepper-motor step counts).

[maukcc]

As this code in ultralcd.ccp says:

static void lcd_sdcard_stop() {
    quickStop();
    card.sdprinting = false;
    card.closefile();
    autotempShutdown();
    cancel_heatup = true;
    lcd_setstatus(MSG_PRINT_ABORTED, true);
  }

it should stop heating and/or switch heaters off when actually printing
But it does not.
I rather like it as it lets me start a new print faster.
from a CE certification standpoint it is wrong and does not comply(hush,hush)

[Blue-Marlin]

But it does not.

Indeed.

autotempShutdown(); //sets only the current exruder to 0. (#if AUTOTEMP)
cancel_heatup = true; // stops the _waiting_ for M109/M190 but does not set the target temperatures.

If we want to stop all heaters it needs a thermalManager.disable_all_heaters();

[Blue-Marlin]

@thinkyhead

Is this new behavior or an old problem?

I don't know. But i think we never had a function/method to clean the command buffer.

Is there a preferred technique to purge the command queue for cases like this?

I'd suggest:

cmd_queue_index_r = 0;
cmd_queue_index_w = 0;
commands_in_queue = 0;

A bit less brutal, but slow:

while (commands_in_queue) {
    commands_in_queue--;
    cmd_queue_index_r = (cmd_queue_index_r + 1) % BUFSIZE;
}

Eventually it also needs to clear the serial_line_buffer[] in get_serial_commands().

[jbrazio]

If we speak about a circular buffer then the way to do it is to set head = tail.

[Blue-Marlin]

@jbrazio
That's not enough here because commands_in_queue is not a function but a variable.
Setting head = tail or tail = head or head = 0; tail = 0 does not matter here, as long as they are the same afterwards.

[jbrazio]

@Blue-Marlin thanks for the heads up, then building upon your initial code we could have something like:

cmd_queue_index_r = cmd_queue_index_w;
commands_in_queue = 0;

[thinkyhead]

#3939 adds clearing of the command buffer for lcd_sdprint_stop().

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.