Bed Adhesion Skirt


I’m pretty new to this, so apologies if this is a dumb question.

I’m having trouble consistently getting the bed adhesion skirt to print. I’m using Cura-LE 2.6.63 and have downloaded the accompanying firmware into my Mini. When I used the prior version of Cura-LE, I had trouble also getting the “prime blob” to print. (In this version I don’t even see an option for a prime blob.)

What happens is that somewhere in the middle of the skirt print, material will start extruding, but it doesn’t extrude at the very start.

Trying to figure this out, I looked at the startup GCODE and I see that, just prior to wiping, there’s a 30 mm retract:
G1 E-30 F75 ; retract filament
And then just prior to printing, there’s an extrusion command, but it’s zero mm:
G1 Z2 E0 F75 ; prime tiny bit of filment into the nozzle

My question is, can this bed adhesion skirt issue be caused by retracting 30 mm and not extruding it back before starting the print? And could I fix it by changing the above line of GCODE to extrude the 30 mm back that had been retracted?


As long as you have filament extruded at some point during the skirt you’re totally fine. The main function of the skirt is to prime the hot end to make sure that it’s full of filament and extruding well when it begins to print your part.

Brim is similar to the Skirt setting, but is used to increase the first layer surface area for improved part adhesion. This setting can be tweaked to be as large as you need, but the defaults should work well.

As for your start gcode question, we use the G92 to set the current extruder position to 0, followed by a filament retraction, and finally some filament reloading:

M82 ; set extruder to absolute mode
G92 E0 ; set extruder position to 0

G1 E-30 F75 ; retract filament

G1 Z2 E0 F75 ; prime tiny bit of filament into the nozzle (pull filament back into nozzle)

Thanks for the quick response. I understand now - I missed that the extruder was operating in an absolute, rather than relative, positioning mode. So the “E0” should be moving the filament back the 30 mm that it had previously been retracted.

It seems, though, that I’d better keep the “bed adhesion” option checked, otherwise there won’t be an attempt to print a skirt and I might miss some of the first layer of the part? I’ve actually had that happen before, even with the bed adhesion option checked.

I’d like to have a little more safety margin. I’m wondering why the extruder doesn’t seem to be returning to the same place?


At the end of a print, there is an E-5 retraction to prevent “oozing” while moving away from the completed print. If you then start a second print, the start script commands (E-30, E0) still leave it 5mm short of full prime.

The skirt (with default min length of 250mm) should be enough to get fully primed. If you want more (or don’t want to use a skirt), then another solution is a “blob”. The “blob” checkbox you saw in earlier Cura 2.6 releases was removed because it doesn’t work with Lulzbot printers. But you can do the same thing by adding a few lines to the start gcode script.

For example, I changed the “E0” line slightly (different Z position), and added 4 more lines that create a “blob” before starting the print:

G1 Z1 E0 F75		; extrude filament back into nozzle
G1 Z2 E7 F75		; extrude a blob to prime nozzle
G1 Z2 E6.5 F600	; retract 0.5mm
G1 X15 Y15 Z10 F5000	;move away from blob 
G92 E0		; reset extruder position to 0

On a first print, where you have preheated and fully primed, this blob will be somewhat large. On a second print (due to the 5mm retraction at end of first print), it will be much smaller – but should still be enough to fully prime the nozzle.

Leave Skirt on unless you need to fill the entire print area. It’s a helpful feature. If you leave your hot end hot, filament may drip out. If this happens you’ll need more filament in the hot end. Manually prime the hot end by turning the extruder gear. If this happens on specific prints reach out to the support team at for detailed help.

Thanks! I’ll give the “blob” gcode a try.

I also found that setting the skirt to several lines was enough to ensure that the hot end got primed prior to the print starting, but it’s always a little nail biting time until the first filament starts coming out.

I came across this thread while trying to understand why I’m having printing issues after upgrading Cura. What I’ve been experiencing is that a significant amount of filament is extracted before probing, such that the skirt is inadequate to prime the hot end before printing starts. On small objects, it is nearly done with the first layer by the time any filament starts coming out.

It’s also visually obvious that nowhere near the same amount goes back in at the end of probing as comes out at the beginning.

After reading this thread, it does appear that the gcode says the right things, but it’s not working that way. I think the difference is that the old version had:

G29                          ; Probe
M204 S2000                   ; set accel back to normal
G1 X5 Y15 Z10 F5000          ; get out the way <<<---
M400                         ; clear buffer
G4 S1                        ; pause
M109 R240    ; set extruder temp and wait
M190 R110; get bed temping up during first layer
G1 Z2 E0 F75                 ; extrude filament back into nozzle

whereas the new one is:

G29 ; start auto-leveling sequence
M204 S2000 ; restore standard acceleration
G28 X0 Y0 ; re-home to account for build variance of earlier mini builds
G0 X3 Y188 F200 ; move away from endstops
G4 S1 ; pause
M400 ; wait for moves to finish
M117 Heating... ; progress indicator message on LCD
M109 R240 ; wait for extruder to reach printing temp
M190 S110 ; wait for bed to reach printing temp
G1 Z2 E0 F75 ; prime tiny bit of filment into the nozzle
M117 Mini Printing... ; progress indicator message on LCD

Note the third line on the top one moves to Z10, whereas it no longer does that. I think that causes the later Z2 E0 move to interact in some way that doesn’t leave time for the filament to extrude. In fact, it even makes a new and frightening BZZZ sound I’ve never heard before.

I do have firmware and I’m planning to upgrade tomorrow when I’m more awake. Maybe that will change the behavior? If not, I guess I’ll increase the minimum skirt distance, but it seems like if I have to do that, then everyone would have to do that.

The start script changes you have noted have nothing to do with net filament position. The new firmware base (1.1.5.xx) has odd problems with “tilting” the G29 mesh if vertical moves are done while an endstop is triggered, and also sets incorrect XY positions (shifting entire coordinate base) if commanded to go beyond an endstop. Those issues led to a number of changes in the firmware AND corresponding changes in start gcode as mitigation. That is why the additional homing command after G29 was added (because G29 refers to beyond-endstop positions on some printers), and it is why there are moves away from endstops before doing any vertical moves. There were also changes to X_Min (changed from 0 to -3) and Y_Max to make the print area more centered on the bed, and to prevent a move to X0 from triggering an endstop. Those changes resulted in some different XY positions for the start scripts, and the move to the bottom-left of the bed was eliminated simply because it wasn’t needed. But none of those changers have any effect on extrusion position.

Note that the latest scripts – due to positions used – should NOT be used with firmware earlier than The new scripts have been changed in concert with the new X_Max positions in and later, and are not intended for earlier firmware.

The root of the problem you’re seeing happens because end-of-print (the end script) retracts 5mm of filament. When a successive print is started, it retracts 30mm (E-30) before wipe/probe, then extrudes 30mm by returning to original position (E0) before printing. That still leaves it a full 5mm (plus any leakage that may have occurred) short of being primed, due to the end-of-print retraction on the previous print.

The only “fixes” are to (1) Manually prime before every print, or (2) Add gcode to extrude another 5-7mm before each print to make sure that 5mm end-of-print retraction is compensated, or (3) Have a large enough skirt/brim to ensure 5-7mm of filament are used so that the nozzle is fully primed. As a 4th option, you could eliminate the 5mm retraction at end-of-print, but that serves a useful purpose of not “oozing” out filament while the hotend is still at temp.

Thanks for the info about the firmware and corresponding changes. I’m not sure what channels I should be watching to stay up to date on this stuff, so far I’ve just been downloading updates, and reading the release notes but I don’t see anything as clear as your explanation.

This, however, isn’t what’s happening in my case. I am starting a print with the filament fully primed. This was not one print after another one, I did several extrudes before starting due to having just changed the bed and replaced the filament. On my subsequent tries, I also reloaded the filament and primed it before starting. I watched these prints start very very carefully because I have a brand new modular bed and my finger was on the power switch in case of unexpected behavior. It definitely does not return the filament to its original position. I’m in the middle of print right now, but I can take a video later if you don’t believe me. It was 100% repeatable. I think there’s something about that G1 Z2 E0 F75 move that is not working correctly. As soon as the printing temp is hit, it just makes a quick loud “BRAP!” and starts printing. It’s extremely obvious watching it that the filament hasn’t moved back in.

As an experiment, I tried tweaking the start script to do the E0 separately:

-G1 Z2 E0 F75 ; prime tiny bit of filment into the nozzle
+G1 E0 F75
+G1 Z2 F75 ; prime tiny bit of filment into the nozzle

And that behaves as I expect, slowly and obviously extruding back all the filament that was retracted (and dripping a bit) before starting to print. And lo, my print was successful.

I’m not sure why this makes a difference; I tried to find whether there is a rule about combined moves that would explain it (e.g. maybe a tiny Z move with a huge E move means the E won’t complete?) but I couldn’t. I’m certainly not an expert on gcode.

Later I’ll capture this on video before and after upgrading the firmware… it shouldn’t make a difference, but I need to upgrade anyway.

Is this a Mini? Which firmware? If you’re using new scripts (new Cura) and old firmware (or old scripts and new firmware) then you are likely crashing into the endstops (the “BRAP!” noise). The G29 probe points exceed X_Max and Y_Min on some Minis, which causes problems for successive axis positioning and axis movement (not sure about E, but definitely causes XYZ problems - and if beyond endstop, E may be prevented from moving as well). The axis movement/position problems were not an issue with older firmware, because it constrained positions to endstops on an attempt to move beyond endstop. The new firmware doesn’t (and also doesn’t clear the leveling matrix on G28). As well, early versions of the 1.1.5.xx firmware did not initialize endstops properly, which meant any move beyond endstop (except for G28/G29) crashed hard and “buzzed” the motors.

There have been a bunch of in-concert changes to firmware and start gcode – made a little at a time, as problems/solutions were found and implemented. It appears pretty stable now, but the firmware and start gcode are definitely a “set” now – and mixing versions from different releases will cause a variety of problems (some minor, some obvious, some neither).

I recommend trying Cura 2.6.66 and the firmware packaged with it ( That will make sure the firmware and start gcode are matched, and may resolve the issue you’re seeing.

It’s a Mini, yes. Firmware And the mystery is solved: I just updated to and it completely changed the behavior of the ‘G1 Z2 E0 F75’ step. Everything seems to be working perfectly now. I captured it all and I’ll put something up on YouTube in a bit if anyone’s curious to see the difference in action. I’ll take your advice and try Cura 2.6.66 and fw, I just wanted to do it by steps to see if the current released one had the same issue.


I can understand that, although I access my machine via OctoPrint from quite a distance away. I’ll have to see if there’s a firmware updater plugin that works properly with the Mini.

Great. Just beware, it isn’t that the firmware changes anything specific to that step. Rather, it is what is happening with endstops and positioning in earlier steps (G28, G29, etc.) that are causing that later step to be adversely affected.

The way the 1.1.5.xx firmware handles endstops, leveling, homing, and the coordinate base for XY is substantially different from 1.1.0.xx – and some combinations of gcode that worked fine in 1.1.0.xx will exhibit issues with 1.1.5.xx (and vice versa).

Best advice (unless you want to spend a LOT of time delving into the gritty details) is to always use a “matched set” of Firmware and Start Scripts as released by Lulzbot. The 2.6.66 release of Cura2 includes and has the most recent “fixes” for these particular issues in both.

There is a plugin for updating firmware from Octoprint that uses AVRDUDE – but I haven’t tried it. I saw one report of someone saying it corrupted the bootloader on one machine, so that scared me off… And I have a laptop that works to update firmware at the printer.

Happy printing!

Well, whatever the interaction was, it’s interacting correctly now.

I installed the firmware update plugin for OctoPrint and successfully used it to re-flash the version I already have (since doesn’t seem to be released yet). So in the future, I’ll be sure to update everything in tandem. Thanks for the advice.

And here’s the recording of the before and the after: The “interesting” bits are at 4:08 with the old firmware and 8:39 with the new one.