Vase mode is retracting

[Mlogue9 3]

Trying to print a vase in vase mode. I attached the 3MF file. 

 

I don't do vase mode too often. However on the first try I noticed it would print about 3-4 degrees around and *poof*, retract! So I went back and turned off retraction in Cura. Now it goes and does the same thing. Vase mode is not supposed to retract at all. The time isn't the problem. The problem is each "layer" retract it does, it makes the thing look like it has smallpox. I cancelled the print. It's possible I am missing something. I often do.

 

Thanks,

Matt

CE3PRO_Spiral_Vase.3mf

[Torgeir 242]

@Mlogue9

 

Hi Matt.

 

I've to say this is one of the best example I've seen in here of using "spiralize mode".

The retractions you observed in the very beginning is Cura making the right "pitch path" before starting "spiralizing".

Use "Notepad++" and look at the gcode. From layer 4 -and on, Cura start spiralizing.

I've checked your gcode file using Cura 4.10.0 and also with S3D (another brand of gcode viewer).

Both of them showed a nice model in preview mode.

There might be something I've missed, but I'm sure @GregValiant can have a look at this.

 

Thanks

Torgeir

[GregValiant 1,250]

Hello @Torgeir and @Mlogue9.

I sliced the 3mf reviewed the gcode, and read the gcode into Autocad to view it.

When Cura puts retractions and primes into a file they are always on their own lines in the form "G1 Fxxx Exxx.xxxxx".  There are never any XY or Z values in a retraction line.  That makes them pretty easy to search for and there are no retractions in the gcode file I generated.  (@Mlogue9 - if you could post your problem gcode file I'll look at it.)

Sorry Torgeir - here we see the travel move (magenta) going from the last normal layer to the start of the first spiral layer (it's within the yellow circle).  There is a short move .133 long and then spiralize starts.  You can see that there is no zhop and within the gcode there is no retraction associated with that location.  The snippet starts at gcode line 6767.

G1 X112.055 Y93.815 E1602.62293
G0 F12000 X111.985 Y93.702  - This is the end of the red travel move
G1 F2281.2 X110.834 Y93.755 Z1.582 E1602.74556 - This is the first extrusion of the spiral
G1 X109.558 Y93.766 Z1.584 E1602.88138

 

 

I don't see anything odd in the gcode I generated.  

 

Edited August 3, 2021 by GregValiant

[Mlogue9 3]

Thanks folks. I peeked at the gcode, it looks like the E keeps climbing even at "layer" breaks. See the attached gcode please. I could show a photo but it simply looks like it has pox, because it had to take a dump every few darn cm. 🙂

CE3PRO_Spiral_Vase3.gcode

[Mlogue9 3]

Well I since you couldn't find a issue in your slice I suppose I could tell you it's uploaded via the web interface of octoprint thru USB to a ender 3 pro with silent board and marlin 2.0.x firmware. I made numeric changes to firmware only and enabled some modules like macros, etc. Nothing related to movement.

 

I printed a vase 6 months ago fine but I was more concerned with velocity painting at time and may not of noticed retracts (dont waste time with VP). The print had no blips though.

[GregValiant 1,250]

My printer is an Ender 3 Pro with the 1.1.5 board but I print via the SD card.  For a while the Creality definition file was way too aggressive for the Maximum Resolution that the mainboard could handle.

 

In Cura under Mesh Fixes is a setting for Maximum Resolution.  If that is a really low number like .025 then try setting it to 0.4 and see what happens (I keep mine at .4 and when I opened the 3mf file it says .4 but double check).  When the number is low the resolution can be too high for the printer processor and the print head can stutter as it runs out of data due to the billions of lines that are .002mm long.  It is especially prevalent on curves and circles and every time the nozzle has to wait for the calculations to catch up it leaves a blob.

[Mlogue9 3]

Never thought of that. Will try... well i set it to min res of 1mm and it is still stopping and retracting. The feedrate was changed from 50% to 200% and it still takes about 6 steps per revolution of the spiral. Probably like 4 or 5 micro-layers. Why is it retracting?

[GregValiant 1,250]

I don't know.  Here is your posted gcode file printed on my printer.  It took half a layer to tune the flow and speed to my .4 nozzle.  I don't see any blobs or zits or other flaws.  Whatever is going on it's downstream from Cura.

 

[Torgeir 242]

This show how a good tuned printer can perform if the model is right.  😏

 

Well done.

Torgeir

Edited August 4, 2021 by Torgeir

[Mlogue9 3]

I just ruled out the model. Togeir (sp?) its not just at the begining, I printed the whole vase and it kept happening. I tried removing mininmum layer time, changing layer size to 4.5mm, scaling down model and it still retracts. The GCODE has no darn retracts in it, it's not due to speed, it's not the model, so it's not cura actually it's the printer or octoprint.

[GregValiant 1,250]

• Right now I think that your printer has a very low probability of being the problem.  There are no firmware retractions in the file and printers only do what they are told.
• Have you tried printing the file using an SD card instead of Octoprint?  If it prints OK from an SD card then you can totally eliminate the printer.  You don't have to print the whole thing, just enough to troubleshoot and then you can abort.
• As I said, blobs can also be caused by the print head stuttering.  Just to be clear, you have watched the extruder moving the filament backwards and forwards (retracting and priming)?
• I don't know Octoprint but is it possible there is a setting within it's interface that could be generating retractions (that would be a slick bit of coding)?
• Is there a possible data hiccup in your setup that is slowing down the data transmission and causing stuttering?  

 

[Torgeir 242]

Octoprint, aha.. 

 

This app can do -lots of thing, -even "adjust" the firmware...

So print this vase without using the Octoprint and see the difference.

 

Octoprint is connected to the printer using the USB to Raspberry PI and from here you're connected via ethernet (LAN) to your PC or -phone. Lots of people use it for remote control and camera monitoring.

This app can be very handy, -but you need to know it very well!

 

Thanks

Torgeir

 

 

 

Edited August 5, 2021 by Torgeir
Text

[Mlogue9 3]

On 8/3/2021 at 11:59 PM, GregValiant said:

It was octoprint - used SD card and printed fine. Just never thought OP could screw up prints so major.

 

 

[GregValiant 1,250]

It's gotta be a setting in Octoprint.  Look through the menus and see if you can find M666 which is gcode for "screw up this print".

 

Good luck.  I'm sure you'll find what's going on.

3d printing with its gcode, complicated slicing software, and a fussy printer that insists on falling out of tune all the time is enough for me.  That's why I don't want to add any more complications like Octoprint or AutoLeveling.  As for firmware, I fall back on my personal rule number four which is NEVER upgrade an operating system.

[Stephen_Feather 0]

On 8/5/2021 at 8:49 PM, GregValiant said:

It's gotta be a setting in Octoprint.  Look through the menus and see if you can find M666 which is gcode for "screw up this print".

Ok, I had to log in just to say thank you for the morning laugh. M666

[GregValiant 1,250]

You're the first person to notice that.  I'm rarely accused of being subtle but in this case I thought the "666" was appropriate.