Bug in 1.2.6/8 vase printing, creating seam?

I've sliced an stl as a 'vase' print in a couple of different versions of Slic3r. In 1.1.7, the movement is correct, though there is extra gcode at each layer change (which should be ignored by the firmware movement planner, so shouldn't make any difference):

...
G1 Z0.595 X124.973 Y115.982 E0.07168
G1 Z0.597 X123.205 Y118.456 E0.05926
G1 Z0.600 X121.755 Y120.144 E0.06806
M106 S255
G1 Z0.6 F9000.000
G1 X121.755 Y120.144 F9000.000
G1 Z0.603 X120.639 Y121.288 E0.08730 F600.000
G1 Z0.605 X119.181 Y122.609 E0.05380
G1 Z0.607 X117.720 Y123.772 E0.05281
...

However, in 1.2.6 and 1.2.8, running the same settings as far as I can tell, I get:

G1 Z0.795 X123.865 Y117.595 E0.07735
G1 Z0.799 X122.929 Y118.797 E0.08322
G1 Z0.802 X122.007 Y119.869 E0.07728
G1 Z0.805 X121.032 Y120.899 E0.07746
G1 Z0.807 X120.211 Y121.684 E0.06204
M106 S255
G1 Z0.6 F9000.000
G1 X120.211 Y121.684 F9000.000
G1 Z0.601 X119.959 Y121.926 E0.01911 F600.000
G1 Z0.604 X118.862 Y122.877 E0.07932
G1 Z0.607 X117.719 Y123.772 E0.07930
G1 Z0.611 X116.492 Y124.640 E0.08216
G1 Z0.614 X115.309 Y125.392 E0.07657

What happens is that the first two layers print fine (these are full bottom layers), then the spiral print starts at 0.4mm height, and in the first full circle travels up to 0.8mm (the above gcode shows the end of this). Then it drops down 0.2mm to Z0.6mm, before doing the next spiral up to 1mm! The rather odd movement going upwards isn't ideal (squashing the previous layer), but the drop in Z at the end of each layer causes a seam, which rather negates the point of doing a vase print... It's like it's trying to do a normal print AND a spiral print.

Anyone else see this? Or are my settings wrong, somehow? I had a quick search for other reports of this, but can't see any, or in the github issues: [github.com]

I've attached the gcode (with gcodes for 10mm to 150mm deleted to keep the size down) so you can see my settings; the stl is available from [www.youmagine.com] . There's also a few odd things happening with the feedrates in the 1.1.7 version, but these do not appear in the 1.2.8 file.

Edit: This is using Slic3r in Ubuntu 14.04, if it makes any difference. Haven't tested under other OSs, yet.

Thanks for looking!

Ian
RepRapPro tech support

Edited 1 time(s). Last edit at 06/12/2015 11:55AM by droftarts.

After a bit of testing, the issue is with absolute/relative extrusion. Turning this on/off alters the behaviour. I sliced the same vase print twice, and the only thing that changed between them was setting extrusion in Slic3r > Printer Settings > General > Advanced > Use relative E distances. This is the example without relative extrusion:

G1 Z1.495 X116.399 Y75.358 E50.15868
G1 Z1.496 X117.526 Y76.147 E50.24526
G1 Z1.498 X118.830 Y77.162 E50.34933
G1 Z1.500 X119.925 Y78.112 E50.44054
G1 Z1.500 X120.155 Y78.332 E50.46061
G1 Z1.5 F9000.000
G1 X120.155 Y78.332 F9000.000
G1 Z1.501 X121.049 Y79.189 E50.53854 F1800.000
G1 Z1.503 X121.969 Y80.163 E50.62289
G1 Z1.504 X122.940 Y81.295 E50.71681
G1 Z1.506 X123.868 Y82.494 E50.81226
G1 Z1.507 X124.635 Y83.590 E50.89642
G1 Z1.509 X125.350 Y84.718 E50.98056

Note the smooth transition in Z. This is WITH relative extrusion (you can tell from the small values of E):

G1 Z1.680 X116.399 Y75.358 E0.08680
G1 Z1.683 X117.526 Y76.147 E0.08658
G1 Z1.687 X118.830 Y77.162 E0.10407
G1 Z1.690 X119.925 Y78.112 E0.09121
G1 Z1.690 X120.155 Y78.332 E0.02006
G1 Z1.5 F9000.000
G1 X120.155 Y78.332 F9000.000
G1 Z1.502 X121.049 Y79.189 E0.07793 F1800.000
G1 Z1.505 X121.969 Y80.163 E0.08435
G1 Z1.508 X122.940 Y81.295 E0.09392
G1 Z1.511 X123.868 Y82.494 E0.09545
G1 Z1.514 X124.635 Y83.590 E0.08417

Same problem as before; in one revolution, rather than going up the layer height of 0.2mm, it goes up nearly 0.4mm, then drops down to the correct layer height.

With the Duet electronics, we tend to use relative extruder moves; Sublime's post here pretty much describes why it's better to use relative moves: [forums.reprap.org]

Switching between relative and absolute modes for vase prints works correctly in v1.1.7, as far as I'm aware. Is this something to do with the new volumetric calculations in Slic3r versions post-1.1.7? I'll raise this as a bug on github.

Ian
RepRapPro tech support

Good observation, Ian. I agree that it is almost certainly a bug.

Dave

I've posted it as an issue, here: [github.com]

Ian
RepRapPro tech support