First perimeter of first layer wrong height

Ak Eric

I recently switched my .4mm nozzle to a 1.2mm volcano on on my delta, Duet Ethernet. I've used these big nozzles on other machines before (RADDS/RRF), but first time here. Big nozzles make any sorts of problems readily visible...

I'm seeing some very weird behavior, and I've exhausted my troubleshooting ability: I'm posting this here since I don't feel this is a slicer issue: When I inspect the gcode, it has all the correct numbers.

When printing a 40mm calibration cube with no infill and 2 shells/walls, the first (interior) shell prints at the wrong height: It's a full mm too high: 1.6mm (should be .6mm). Then when the 2nd shell prints, it prints at the correct height: .6mm. Since these layers are so thick, it's safe to say its pretty obvious something is wrong: Inside layer doesn't stick well, and outside layer is super squished into the plate.

Printing with a single shell has weird behavior too: It's printing the first layer at 1.8mm, a full layer height too much (+.6mm), and then maintains that .6mm offset throughout the print.

I've done tests in Simplify3D with the 'first layer height' settings: Seems to have no effect on this behavior. In fact, I set it so my 1st layer height/width is 100% of all others to rule out slicer issues.

If I inspect the gcode, it is clearly telling it to to the correct z-height, here's a snippet for a 1-shell cube (and the 2-shell cube keeps the same z-height values throughout):

G1 Z0.600 F9000 ; This is reporting 1.2mm in DWC
; process Process1
; layer 1, Z = 0.600
T0
; tool H0.600 W1.200
; outer perimeter
G1 X14.111 Y11.319 F9000
G1 E1.0000 F1800
G1 X-24.689 Y11.319 E10.9176 F900
G1 X-24.689 Y-27.481 E10.9176
G1 X14.111 Y-27.481 E10.9176
G1 X14.111 Y11.319 E10.9176
; layer 2, Z = 1.200
M106 P0 S255
G1 Z1.200 F9000 ; This is reporting 1.8mm in DWC
--- more printing...

To break down the weirdness;

One shell behavior:

layer1 1.2mm <- .6 mm too high.
Layer2 1.8mm < +.6mm, correct offset, but wrong height.
etc, add .6mm each layer as it should

Two shell behavior:

layer1 Inner shell :1.6mm <- 1mm too high
layer1 Outer shell layer1 : .6mm <- correct
Layer2: Inner/Outer shells : 1.2mm for both < -correct
Layer3 : etc, add .6mm for each layer as it should

Since I've confirmed the gcode has the correct values, but clearly something wrong is happening when its printing, confirmed by visual inspection and numbers from the DWC, this feels like a firmware issue: Where can I start looking for these oddities?

Ak Eric

I tracked it down, and I would place this as a bug in firmware retraction, unless I'm doing something wrong. I'm on v1.20 (2017-12-23)

I'd been printing without a skirt: Thinking that it seems to be only the first perimeter that has this issue, I figured I'd try printing with a skirt, and see if the skirt gets the problem instead of the model I'm printing: I tried a skirt with a 10mm offset from the part, with two shells. Sure enough, on the outer skirt perimeter (the first one printed), the problem showed up (printing too high). But the inner skirt, and the print itself were then fine.

I had the idea: The 'bug' seems to exist until the first retraction: It prints a full segment/perimeter, then retracts, then starts the next segment. I'm using firmware retraction. These are my settings for the volcano (currently, still tuning):

M207 S5.0 R0 Z1.0 F6600 T6600

The z-lift has a 1.0mm offset, which is the same as the offset being plugged into the mult-shell print problem. So I set that to zero, reset the machine and: Successful first layers.

So my suspicion is that the M207 z-hop feature is somehow keeping the entire first segment 'hopped' until it hits the first retract. My guess is that on smaller nozzles, this just isn't as noticeable than a 1.2mm volcano? Thoughts @dc42 ?

JohnOCFII

Are you using pressure advance (M572?)

There have been issues noted with the skirt when using Pressure Advance with Simplify 3D, but perhaps you've found the reason why others weren't seeing issues with the actual print, but only with the skirt...

If you have access to another slicer, I'd try to slice the same file and see if the behavior changes.

Also, you might want to upgraded to 1.21 just so you are using the most current released software.

John

dc42

@ak-eric said in First perimeter of first layer wrong height:

I tracked it down, and I would place this as a bug in firmware retraction, unless I'm doing something wrong. I'm on v1.20 (2017-12-23)

I'd been printing without a skirt: Thinking that it seems to be only the first perimeter that has this issue, I figured I'd try printing with a skirt, and see if the skirt gets the problem instead of the model I'm printing: I tried a skirt with a 10mm offset from the part, with two shells. Sure enough, on the outer skirt perimeter (the first one printed), the problem showed up (printing too high). But the inner skirt, and the print itself were then fine.

I had the idea: The 'bug' seems to exist until the first retraction: It prints a full segment/perimeter, then retracts, then starts the next segment. I'm using firmware retraction. These are my settings for the volcano (currently, still tuning):

M207 S5.0 R0 Z1.0 F6600 T6600

The z-lift has a 1.0mm offset, which is the same as the offset being plugged into the mult-shell print problem. So I set that to zero, reset the machine and: Successful first layers.

So my suspicion is that the M207 z-hop feature is somehow keeping the entire first segment 'hopped' until it hits the first retract. My guess is that on smaller nozzles, this just isn't as noticeable than a 1.2mm volcano? Thoughts @dc42 ?

M207 Z-hop only applies if you are using firmware retraction - but I don't see any firmware retraction commands in tha GCode snippet you provided.

Ak Eric

@johnocfii : No pressure advance. I've never been able to get it to work well despite a lot of fiddling. Doing a test in another slicer is a good idea, but since the gcode looked ok, it seemed like overkill.

@dc42 : Ah, good catch. That's a truncated piece of gcode. I'll do a larger snip when I'm hope that shows the firmware retraction bits.

Right now, I've disabled z-hop in my firmware retraction setttings:

M207 S5.0 R0 Z0.0 F6600 T6600

So it starts printing with no hop, and no bug either. Then have a macro in DWC where I can turn it back on after it prints the first shell, and everything behaves as it should. The nozzle starts hopping during retractions. So this still really feels like a firmware retraction issue. But again, will get a better gcode snippet later.

Ak Eric

Below is the gcode from first line through layer 2, where you can see the G10 & G11's.
And that's where I noticed it: There's a G10 right after the 'M98 PscriptStart.g' line (called out below). And then a few lines later, another G10. So it's retracting twice, and thus hopping up, but not down. I somehow hadn't noticed this before, . Since all this is being added by Simplify3D, I need to track down why it's placing a retract at the beginning of the gcode.

So I take back all my comments about this being a firmware bug. I just missed that line, and presumably it's the culprit. Which makes me wonder how long this has been happening in my config... Research will continue...

G90
M83
M106 P0 S0
M140 S60 T0
M190 S60
G10 P0 S200 R0
M98 PscriptStart.g          ; Run the starting script macro
G10                         ;  <- AAAAH WHAT IS THAT???!?!!?!?

G1 Z0.600 F9000
; process Process1
; layer 1, Z = 0.600
T0
; tool H0.600 W1.200
; inner perimeter
G1 X18.200 Y18.200 F9000
G1 E1.0000 F1800
G1 X-18.200 Y18.200 E10.2423 F900
G1 X-18.200 Y-18.200 E10.2423
G1 X18.200 Y-18.200 E10.2423
G1 X18.200 Y18.200 E10.2423
G10

; outer perimeter
G1 X19.400 Y19.400 F9000
G11
 
G1 X-19.400 Y19.400 E10.9176 F900
G1 X-19.400 Y-19.400 E10.9176
G1 X19.400 Y-19.400 E10.9176
G1 X19.400 Y19.400 E10.9176
G10

; layer 2, Z = 1.200
M106 P0 S255
; inner perimeter
G1 X18.200 Y18.200 F9000
G1 Z1.200 F9000
G11
 
G1 X-18.200 Y18.200 E10.2423 F1203
G1 X-18.200 Y-18.200 E10.2423
G1 X18.200 Y-18.200 E10.2423
G1 X18.200 Y18.200 E10.2423
G10

; outer perimeter
G1 X19.400 Y19.400 F9000
G11
 
G1 X-19.400 Y19.400 E10.9176 F1203
G1 X-19.400 Y-19.400 E10.9176
G1 X19.400 Y-19.400 E10.9176
G1 X19.400 Y19.400 E10.9176
G10

Ak Eric

I went back looking at S3D generated gcode several years old, across multiple different printer profiles : Every single one of them has a retraction right at the start of the gcode. This makes me think it has nothing with how I've setup any of these profiles, and it's something S3D is manually adding for some reason.

So if you're not using 'firmware retraction with z-hop', this seems to be no big deal:

Before anything else, retract a little bit for 'some reason' S3D finds important.
Start the first segment.
First segment ends, retract before starting next segment.
Unretract, begin next segment.
etc...

But, if you're using 'firmware retraction with z-hop', this poses problems:

Before anything else, retract a little bit for 'some reason' S3D finds important. Which starts the z-hop: Nozzle goes up, but doesn't go down.
Print the first segment too high.
First segment ends, retracts again (first 'real' retraction that should happen), but seems to stay at current 'too high' z-height: Doesn't 'double-z-hop'.
Toolhead moves to next segment.
Unretract happens, which triggers the 2nd part of the z-hop: Nozzle then goes down to where it should, 2nd segment prints just fine.

I checked some old Slic3r gcode: It's similar, but different, and doesn't cause this issue:

Retract a little bit before the print: This would hop the nozzle up.
Move the toolhead into position.
Unretract before first segment is printed: Lowers nozzle to correct location.

So, I'm going to contact S3D support an see what they have to say on this matter

dc42

Except in very old firmware versions, RepRapFirmware will ignore a second G10 if there hasn't been a corresponding G11 to cancel the first one.

Ak Eric

S3D Support got back with me. Looks like they hardcode that initial retraction

But they did provide a solution that I'll give a shot:

"Although it is not possible to remove the initial retraction, we do have a suggestion to help you move forward. We noticed that all the retractions that are of interest to you are preceded by the tool-change command T0. Therefore, in your post-processing script you could consider including this as a condition with an IF statement or use the TOOLREPLACE as mentioned in this forum post. Then you could delete the remaining retraction prior to the tool-change using the DELETE command."