M486 Cancel object causes pause

ajdtreyd

Hi,
I have a print going right now for which I had to cancel an object (object 0 of 0-4) because it lost bed adhesion. M486 cancelled the printing of the object as expected, however, now the printer pauses at the final position for object 4 for about 3sec before proceeding to object 1.
I assume this pause is happening while skipping past the gcode for object 0, but is this pause expected behavior? It's not really a problem for this particular print since infill is the last feature to print per layer, but if I were printing no infill and external perimeters last it would certainly result in visible blobs.
Anyway, just wanted to find out if this is expected and, if so, are there any strategies to reduce the length of the pause while the canceled object's gcode section is skipped.

Thanks,
Trey

Edit:
I'm running RRF 3.3 on a Duet 2 Wifi in a Rostock Max

T3P3Tony

@ajdtreyd the firmware needs to reed the gcode file until it finds the next object. depending on the number of gcode lines in the object being skipped this could take some time - leading to a perceptible pause.

There is not a strategy to reduce this pause right now (although as you point out printing in fil last will help mitigate the impact). We are discussing options for improving this in the future.

pldusik

Hello there, I'm contemplating whether PrusaSlicer could get support for the recently added M486 order that Marlin presented in v2.0. I realize this component is executed along these lines in with the drop objects octoprint module however it seems like that module hasn't been refreshed in some time. What's more, with the coming help of Python 3, that module may fall into a state where it can presently don't be utilized. Here's some more data about how marlin carries out it.

dc42

RRF doesn't care whether objects are labelled using M486 or using comment lines, because it recognises both. PrusaSlicer already has a "Label objects" option on the Print Settings page, and that generates comments that are sufficient for RRF to implement object cancellation.

ppaukstelis

@t3p3tony I had brainstormed a bit on how to avoid pausing. It would be possible to have a comment/command that would provide the number of lines to skip ahead, something like M486 Q1652. Downside is that it would require either the slicer or some post processing to insert them.

dc42

@ppaukstelis unfortunately there are some commands that must be executed or remembered even when skipping an object, such as tool changes and fan speed settings. Also, I don't think it is guaranteed that after the slicer signals the start of a new object, the first move will be a travel move. Therefore RRF interprets many of the skipped commands and tracks the head position through those commands.

If it was guaranteed that the slicer always started a new object with a travel move, then RRF would not need to track the head position, which would make skipping moves faster.

Alternatively, if the pause while skipping an object is not of itself a problem, but nozzle oozing during the pause is, then we could execute a macro when switching from a printing to a cancelled object, and another when switching back to a printing object. In those macros you cold move the print head to the edge of the build plate, and clean/re-prime the nozzle.