Slic3r just won't stick the first layer...

[mhackney]

Try as I might, I simply can not get Slic3r to get the first layer to stick and the initial skirt is a complete disaster. I've configured all of the parameters in Slic3r to match my KISS settings. I have the same Z = 0, same temps, same filament. I can attempt to print Slic3r gcode and fail then immediately load KISS and it prints beautifully, immediately go back to Slic3r gcode and fail. (and this is on the magical PEI surface as well as blue tape)

When KISS starts the skirt, the nozzle comes down to the bed, and starts to extrude IMMEDIATELY. I get immediate stick of the filament and all is well on the skirt. Same thing happens when it moves the nozzle to start printing the part.

Contrast this with Slic3r gcode - the nozzle comes down to the bed (I've measured the gap at this point and it is exactly the same as where the KISS nozzle started) and starts to print the skirt. BUT, it takes 4-5 cm before anything starts coming out of the hot end and when it does, it sort of "tapers" in. I see the extruder moving and it does appear to move slower than with KISS. As this happens, nothing sticks to the bed. Instead, the PLA balls up around the nozzle. Once that happens, it's all over. Even attempting to remove the balled up PLA with tweezers in mid stream, when the print head moves to the start the part, it does not stick immediately like KISS prints do. This is with holding EVERYTHING the same EXCEPT the slicer.

It is very frustrating and I never had these problems with earlier versions. I'm on RC3 now but RC 2 and 1 did the same thing. It's almost like Slic3r is trying to "ease into" the print. Has anyone had success printing with Slic3r? If so, could you run through your settings and maybe print a small test part and send me the gcode for it?

cheers,
Michael

[enggmaug]

I normally print with slicer. I'm not home now, so I cannot send you any gcode...

Anyway, if the extruder extrudes faster in Kiss, I would try to raise the extrusion multiplier in Slic3r settings, just to see how it works.

Are you printing with the Kraken ? I personally use the stock hot end for now... my kraken is not ready yet.

[mhackney]

Thanks, yes printing with Kraken now - it has a .4mm orifice. I've had these problems with the stock hot end and the E3D as well.

[bubbasnow]

I made the change from kiss to slicer last night, I had to change from simple to the advanced view.

then i just copied the assembly manual settings directly in, except for the dual extruder part and It stuck really well to the PEI surface.

[img]https://lh4.googleusercontent.com/-01ZE ... 082914.jpg[/img]

dont mind the discoloration... its a different setting with temps and retracts with the off nozzle.

[mhackney]

Yeah, I'm in expert mode and basically did the same thing. You have an E3D installed correct? It should have similar behavior to my Kraken.

[bubbasnow]

yea 2 of them-0.4 mm tip

[enggmaug]

I wanted to send you some GCode, but realised I sliced it for .35 nozzle. I did not install my kraken, so I still don't have .4 nozzle that works, so I could not send you gcode that I tried, and approved....

Sorry...

[Captain Starfish]

I had the same problem and got more and more aggressive with the ABS juice until the day it pulled glass out of the bed as I lifted a finished part. Ooops.

A few things have helped get it better to the point where I'm now happily printing on Elmer's purple vanishing glue with a 50ºC bed.

First, print settings.
1. Layer height: 0.25mm first layer.
2. Advanced: 120% extrusion rate on first layer.
The combination of these two seems to smoosh the first layer down pretty well.

Second, avoiding that tapering in rubbish.
I do this by using the following end-of-job G-code

Code: Select all

M104 S0
M140 S0
G92 E0
G1 E-80 X0 Y0 Z300 F6000
G28
M84

this retracts 80mm fairly quickly as the effector is taken up to z=300, preventing blobbing and jams in the hot-end and pulling the filament back so you can see the end in the bowden tube. I only mention this so you can see how my unit is left for the start of the next job.

I bring everything up to temperature and let it settle, then when I'm ready to print I extrude 100mm at 300mm/min and hit the "run" button as that's going. About 2cm worth of filament gets extruded, nozzle is primed, and as soon as the platform starts heading down I just swipe the waste away and into the bin. The hot end gets to the plate and starts laying straightaway, no mucking around with tapering in and balling at all.

[mhackney]

Thanks. I'll try the 120% extrusion rate. I've tried something similar with priming the nozzle but it still does the "taper in" thing on the skirt. Drives me crazy, KISS does such a nice job compared to this.

[Captain Starfish]

I've found that if the temps aren't spot on to start and I extrude/prime, run, and the thing halts for a few seconds to stabilise temperatures then I get your problem. The priming extrude operation needs to happen immediately before the nozzle drops to the bed to start the print for the prime to work properly.

[mhackney]

Understood and that is exactly what I do. Interestingly, I just took the first layer from a KISS gcode file and replaced the Slic3r 1st layer with it. I got a great first layer and then Slic3r took over. I can't believe no one else has 1st layer problems with Slic3r.

[Captain Starfish]

Don't stop there, time to analyse the difference. What's KISS doing differently? Some preambly priming mumbo jumbo? Different Z height? Different traverse speeds? Different extrude rate?

[mhackney]

Looks like different extrude amount/rate. The Z height is identical (I configured it that way on purpose).

[bubbasnow]

did you enter any bed roughness in kiss settings?

[mhackney]

No, never have.

[bubbasnow]

must be global warming

[mhackney]

So, looking at the slicer code in more detail side-by-side with KISS, I find this (I have verbose commenting on) in Slic3r:

G21 ; set units to millimeters
M104 S185; set temperature
G28
G1 Z300 F7500
M109 S185 ; wait for temperature to be reached
G90 ; use absolute coordinates
G92 E0 ; reset extrusion distance
M82 ; use absolute distances for extrusion
G1 F1500.000 E-3.00000 ; retract
G1 Z1.200 F12000.000 ; move to next layer (0) and lift
G92 E0 ; reset extrusion distance
; New Layer ----------------------------------------------
G1 X-27.387 Y28.880 F12000.000 ; move to first skirt point
G1 X-27.387 Y28.880 F12000.000 ; move to first skirt point
G1 Z0.200 F12000.000 ; restore layer Z
G1 E3.00000 F1500.000 ; compensate retraction
G1 X-28.657 Y28.850 E4.04425 F300 ; skirt

See the 3 lines in red. This would make sense given my retract value of 3mm. Now compare to KISS:

G28
M104 S185
M190 S0
M109 S185
; Reset extruder pos
G92 E0
; BEGIN_LAYER_OBJECT z=0.20
T0
M104 S185
G92 E0
; 'Skirt', 0.3 [feed mm/s], 5.0 [head mm/s]
G1 X45.7 Y24 Z1.2 E0 F12000
G1 X45.7 Y24 Z0.2 E0
G1 E3 F1500
G1 X45.13 Y24.5 E3.0505 F300

KISS does an explicit "prime" of my retract length (3mm) with no previous retract as shown in red.

Slic3r seems "technically" correct but does not working practice for me. KISS seems like it should blob but works well in practice (no initial blob).

Seems like this "prime the pump" should be configurable. Now I need to do some tests with Slic3r and change it's initial behavior to prime. I also am doing a few calculations for the perimeter extrusions to see if they are full amounts for the given nozzle diameter, widths, etc or if they are "tapered in". I've done these for KISS and it is definitely extruding the full amount I would expect.

Then in an even more inexplicable example, Slic3r does this at the end of the skirt:

G1 X-28.657 Y28.850 F9600.000 E12.93884 ; retract
G1 X-30.237 Y28.740 F9600.000 E12.70374 ; retract
G1 X-31.377 Y28.600 F9600.000 E12.53325 ; retract
G1 X-32.697 Y28.380 F9600.000 E12.33461 ; retract
G1 X-34.257 Y28.050 F9600.000 E12.09792 ; retract
G1 X-35.367 Y27.750 F9600.000 E11.92725 ; retract
G1 X-36.837 Y27.290 F9600.000 E11.69861 ; retract
G1 X-38.127 Y26.810 F9600.000 E11.49430 ; retract
G1 X-39.497 Y26.220 F9600.000 E11.27288 ; retract
G1 X-40.617 Y25.670 F9600.000 E11.08767 ; retract
G1 X-41.887 Y24.970 F9600.000 E10.87241 ; retract
G1 X-43.377 Y24.050 F9600.000 E10.61248 ; retract
G1 X-44.537 Y23.230 F9600.000 E10.40161 ; retract
G1 X-45.153 Y22.757 F9600.000 E10.28631 ; retract
G1 F1500.000 E10.13631 ; retract
G1 Z1.200 F12000.000 ; lift plate during travel
G92 E0 ; reset extrusion distance
G1 X-27.387 Y24.281 F12000.000 ; move to first perimeter point
G1 Z0.200 F12000.000 ; restore layer Z
G1 E3.00000 F1500.000 ; compensate retraction
G1 X-28.530 Y24.254 E3.03985 F300 ; perimeter

The total length of retraction is 3mm but it is done in 15 discreet steps at a much higher rate than a normal retraction. I have no idea what the net effect of that is but it just seems very odd and overly complex. It then does a compensation (in red) at the normal rate.

[mhackney]

Wow, Slic3r does the multi step retract everywhere it needs to retract. I've counted 20 discreet steps in places like going from printing a perimeter to infill. Very odd.

EDIT: I've fond a place where 33 micro retracts are performed!

[Eaglezsoar]

Wow, Slic3r does the multi step retract everywhere it needs to retract. I've counted 20 discreet steps in places like going from printing a perimeter to infill. Very odd.

Are you using the RC versions of Slic3r or 0.999?

[mhackney]

This is RC3. I don;t recall seeing this in the pre RC versions but then again, I haven't tried to use Slic3r until recently when the RCs were available - and that's when I started having problems with it.

[Eaglezsoar]

This is RC3. I don;t recall seeing this in the pre RC versions but then again, I haven't tried to use Slic3r until recently when the RCs were available - and that's when I started having problems with it.

Try using the older version.

[mhackney]

It looks like this is an issue that others have seen. I checked an older version and it is not generating this code. I have not tried printing with that older gocde yet though.

It turns out that the "wipe while retracting" setting is what triggers this code. The higher speed for the multiple bursts of wipe retract may be causing missed steps.

Now that I've discovered these things I can generate some clean gcode, manually add an initial prime and see what happens!

It really is amazing how primitive slicers are at this stage.