Nozzle sits/oozes on current object until next object cancels

[DroneMang]

Hi,

The issue I am having is that when I cancel an object, the nozzle just sits on the part it was printing, and then the progress bar slowly moves up until Octoprint figures out where to start printing next. If I have many objects remaining, and cancel them all, then this takes a very long time with lots of oozing.

I am using S3D, and I have followed your setup guide, I am using relative extrusion. The only thing I have not tried is to place G1 Z.* in the allowed GCODE, which I will try.

When you hover over the i icon in the octoprint settings for Allowed GCODE, these commands pop up: G1 Z.* , G0 F/d + Z, M104, M109, M240

Could you explain what each of the commands you have suggested will do when cancelling an object? As in what would the expected behaviour be? Wouldn't the temperature commands be taken from the next object? Why would you need those commands from the cancelled object?

My solution would be to put:

Before skip GCODE: G91, G1 Z10 E-2 F3000

After skip GCODE: G1 Z-10 E2.5 F3000, G90

This would put it into relative extrusion mode, raise the nozzle by 10mm, retract 2mm of filament, then cancel the object, then undo these changes plus an extra 0.5mm prime of the nozzle, and put it back into absolute mode, all while octoprint advances the progress bar to the next part. I looked through my GCODE file that is configured for relative extrusion, and I expected the moves to be done with a G91 at the start of the script, but there is a single G90, so when we check the box for relative extrusion, does G90 still apply? I tried this, but everything just hung up but the progress bar was still moving at a very slow pace, and when I opened up the settings the After skip GCODE's were gone.

What do you think about this remedy? I am not sure if there should be a G91 in the before skip or G90 in the after skip GCODE's. Do you need a comma after the last GCODE command in these blocks?

This is a great feature! Good work.

DroneMang

[paukstelis]

What kind of hardware are you running OctoPrint on? There really is no reason it should sit for any extended period. Can you check your logs? If you have a plugin_cancelobject_cancelobj.log that should tell you how long it is taking to skip each object.

G1 Z.* allows any Z axis-only moves to occur during skipped objects
G0 F/d+ Z sets the Z axis feedrate (this command was used by Cura)
The other commands are for heating, feedrate, acceleration, etc.

[DroneMang]

Here is the log I have. One of the last entries has a very long time since that is when I tried the proposed solution above.

I have a standard RPi 3B+, RPi Camera, SKR Pro

plugin_cancelobject_cancelobject.txt

I am using Linear Advance, Firmware Retract, S-Curve accel, Junction Deviation, to use firmware retract with S3D I have to post process the gcode within s3d.

Here are my S3D settings:
FT-6 DLEx RFD900 Tripod 2.zip

I can post my Marlin 2.0 files too if you want.

Thanks!

[paukstelis]

Can you also provide your Gcode? The log shows it is taking 21 seconds to skip the object which is way too long. What other plugins do you have installed?

[DroneMang]

RFD900_5-2-tripod.zip

Here are the plugins and gcode thanks!

[paukstelis]

Looks like you are printing the parts sequentially, is that correct? If that is the case then you can anticipate some delay after cancelling, because it has to go through ~143,100 lines of gcode before it reaches the next object (for the first object). How long it takes dependent on the system you are running OctoPrint on.

[DroneMang]

In your setup the line:

Create one process for each object or group of models you want to be able to cancel. Assign models to processes.

Doesn't that mean I have to print sequentially in order to make use of the cancel objects plugin? How would I assign a process to each object but then not print sequentially? I guess I don't check the sequential box when I hit print in S3D, but assign the process to the objects the same?

So, what before and after gcodes would you recommend to keep the long pause from oozing on the part?

Will my solution work? Can you check the formatting here? Did I just need G1 Z.* in the allowed commands section for these to work? Do I need the G90 at the end like this?
Before skip GCODE: G91, G1 Z10 E-2 F3000
After skip GCODE: G1 Z-10 E2.5 F3000, G90

I know you said:

G1 Z.* allows any Z axis-only moves to occur during skipped objects

but how would this play out? Don't the z-movement commands come from the GCODE made by S3D?

Another question, do I need the M486 Cancel Objects feature enabled in Marlin to use this plugin? Do these have anything to do with each other?

Also, say I want to cancel all the remaining objects in a big sequential print like I posted above. Should I include some commands to turn off the hotend and heat back up between cancelling parts and force a wait before starting printing?

Thanks for really looking at this, I want to get this working reliably with sequential printing!

[paukstelis]

No, you don't have to print sequentially. For S3D you just have to have one model per process. Do not click Sequential printing after you click Prepare to Print.

[DroneMang]

OK.

I do prefer to print sequentially, how can this best be setup with your plugin?

Thanks.

[DangeMask]

Same issue here. I was printing 10 copies of the same object and one didn't adhere to the bed, so I canceled it. Then every layer the nozzle stayed at one place for a few seconds, waiting to iterate through the canceled object rows. Verified this on next print, looking on gcode viewer, where I saw the skipped moves appear on screen while the nozzle was waiting in place.
When printing with PETG, the pause creates a "pimple" on the object.
On my side, it can be probably fixed by upgrading HW (RPi 2).