[3.1.1] Issue Parsing Layer Change

Phaedrux

@CCS86 said in [3.1.1] Issue Parsing Layer Change:

I put ;E comments on every line in my start gcode with a Z move, and even tried running code from Superslicer. The result is the same.

Can you show your current start and end gcode?

CCS86

;//////// START GCODE \\\\\\\\


G90                                          ; abs pos
M82                                          ; abs ext
M106 S0                                      ; fan off



M104 S170                                     ; Set hotend
M140 R33                                      ; Set bed

G28                                           ; Home

M109 S170                                   ; Wait for hotend
M190 R33                                    ; Wait for bed
G4 S10                                       ; Pause


M557 X12:201 Y34:151 P12:9
G29 S0                                      ; Probe bed mesh
M376 H3                                     ; Mesh taper

G1 Z60.0 F5000                              ; E
G92 E0                                      ; Zero extruder
G1 X20 Y20 E-4 F4000

M109 S210                                    ; Wait for hotend

G1 X10 Y0 Z.3 F2000	                     ;E
G1 E0 F2000
G1 X50 E5 F1200
G1 X140 E11 F1200
G1 Y2 Z.1 F9000 		             ;E
G4 S2
G1 Y3 F9000
G1 X20 Z.07 F9000 	                     ;E
G1 Z5 			                     ;E

G92 E-.7                                      ; Comp for ooze


;///////////////\\\\\\\\\\\\\\

;////// END GCODE \\\\\\

M400 ;wait for clear buffer
G91 ;relative positioning
M83 ;relative extruder
G1 Z5 E-3 F4000
G28 XY
G1 E3 F1500
M106 S128
M104 S0 ;extruder heater off
M140 S0 ;heated bed heater off
M18 ;steppers off
G4 S120
M106 S0

;////////////\\\\\\\\\\\\

CCS86

I tried offloading stuff with Z calls to NozzlePrime.g, behavior is still the same. I noticed that it shows the current layer as 0 until just after the probing sequence, where it jumps quickly to layer 1, then layer 2, where it stays stuck for the rest of the print. Is it possible that something inside the G29 command is breaking this?

Here is what a new piece of gcode looks like:

; generated by SuperSlicer 2.2.53 on 2020-10-03 at 20:25:26 UTC

; 

; external perimeters extrusion width = 0.40mm
; perimeters extrusion width = 0.40mm
; infill extrusion width = 0.40mm
; solid infill extrusion width = 0.40mm
; top infill extrusion width = 0.40mm
; support material extrusion width = 0.40mm
; first layer extrusion width = 0.40mm

; object:{"name":"Hero 9 Lens Cap","id":"Hero 9 Lens Cap.stl id:0 copy 0","object_center":[32.949028,122.885129,0.000000],"boundingbox_center":[32.949028,122.885129,3.925000],"boundingbox_size":[33.549999,33.549999,7.850000]}

M107
;//////// START GCODE \\\\\\\\


G90                                          ; abs pos
M82                                          ; abs ext
M106 S0                                      ; fan off
M220 S100									 ; Set speed factor back to 100% in case it was changed
M221 S100									 ; Set extrusion factor back to 100% in case it was changed
M290 R0 S0									 ; clear babystepping
M104 S170                                    ; Set hotend
G28                                          ; Home



M140 R35         ; Set bed
M109 S170                                   ; Wait for hotend
M190 R35         ; Wait for bed
G4 S10                                      ; Pause



; Replaced marker: M557 TBD  									  ; parameters will be set automatically
M557 X12:63 Y92:153 P4:5
; End marker
;M557 X20:190 Y10:180 S15                     ; Define mesh grid
G29 S0                                        ; Probe bed mesh
;G29 S1 P"mesh.csv"
M376 H3                                       ; Mesh taper

G92 E0                                        ; Zero extruder
G1 Z60.0 E0 F5000                             
G1 X20 Y20 E-4 F4000

M109 S215              ; Wait for hotend



M98 P"0:/sys/PrimeNozzle.g"

;///////////////\\\\\\\\\\\\\\
G21 ; set units to millimeters
G90 ; use absolute coordinates
M82 ; use absolute distances for extrusion
G92 E0
; Automesh: begin layer 0
G1 Z0.250000 F10200.000
G1 E-2.50000 F2400.00000
G1 Z0.950000 F10200.000
G1 X21.559 Y103.095
G1 Z0.250000
G1 E0.00000 F2400.00000
G1 F1800.000
M204 S1600
G1 X23.618 Y102.888 E0.02789
G1 X42.248 Y102.887 E0.27900
G1 X43.816 Y103.005 E0.30019
G1 X45.811 Y103.499 E0.32789
G1 X47.258 Y104.136 E0.34919
G1 X48.911 Y105.219 E0.37584
G1 X50.066 Y106.285 E0.39702
G1 X51.051 Y107.510 E0.41820

...


G1 X15.283 Y106.923 E1.80679
G1 X15.842 Y106.275 E1.81832
G1 X16.811 Y105.362 E1.83626
G1 X17.501 Y104.833 E1.84798
G1 X18.633 Y104.140 E1.86586
G1 X19.408 Y103.766 E1.87746
G1 X20.669 Y103.313 E1.89553
G1 X21.501 Y103.110 E1.90707
M204 S2500
G1 X21.583 Y103.446 F10200.000
G1 F1800.000
M204 S1600
G1 X23.625 Y103.234 E1.93474
G1 X42.248 Y103.234 E2.18575
G1 X43.761 Y103.347 E2.20620
G1 X45.701 Y103.828 E2.23314
G1 X47.091 Y104.439 E2.25361
G1 X48.705 Y105.498 E2.27962

...

; stop printing object Hero 9 Lens Cap.stl id:0 copy 0
M106 S127.5
; Automesh: begin layer 1
M204 S2500
G1 Z0.400000 F10200.000
G92 E0
G1 E-2.50000 F2400.00000
G1 Z0.600000 F10200.000
G1 X13.793 Y136.284
G1 Z0.400000
G1 E0.00000 F2400.00000
G1 F2700.000
G1 X13.568 Y135.759 E0.00490
G1 X13.197 Y134.457 E0.01654
G1 X13.038 Y133.526 E0.02464
G1 X12.951 Y132.193 E0.03611
G1 X12.974 Y112.892 E0.20187
G1 X13.171 Y111.435 E0.21450

...

CCS86

And again, this file, like every file simulates perfectly fine. I wish @chrishamm or @dc42 could help us out here. The fact that simulation senses layers without issue should be a solid diagnostic clue.

dc42

On my list to look at in 3.2beta.

CCS86

I did some more diagnostics and narrowed it down to a very unlikely culprit. The line:

G1 X20 Y20 E-4 F4000

Is what causes the layer counter to jump from 0 / 49 to 2 / 49, where it stays. I put 6 second dwells between each line of code in that area, to act like single block mode.

Any ideas how that line could possibly be involved?

Phaedrux

Are you sure it's that one and not the Z60 before it?

G1 Z60.0 E0 F5000
G1 X20 Y20 E-4 F4000

CCS86

@Phaedrux said in [3.1.1] Issue Parsing Layer Change:

Are you sure it's that one and not the Z60 before it?

G1 Z60.0 E0 F5000
G1 X20 Y20 E-4 F4000

I had a 6 second dwell after the "G1 Z60.0 E0 F5000" line as well. It executed that lift and sat for 6 seconds with layer 0 / 49 still registering. It jumped to 1 /49 then 2 / 49 almost immediately after beginning the G1 X20 Y20 E-4 F4000 line.

CCS86

Well, I kept hacking at this problem. Since it didn't like:

G1 X20 Y20 E-4 F4000

I broke it up into the XY and then the E move, like this:

M557 X12:65 Y88:148 P5:5
G29 S0                                        ; Probe bed mesh
M376 H3                                       ; Mesh taper

G92 E0                                        ; Zero extruder
G1 Z60.0 E0 F5000   
G4 S2 
G4 S2
G4 S2                         
G1 X20 Y20 F4000
G4 S2 
G4 S2
G4 S2 
G1 E-4 F1800

That change alone caused the layer counter to stay at 0/49 through the whole probing and prime sequence. Jumping to 1/49 only once the the print began, and continuing to count layers correctly for the rest of the print.

I'm shocked, but hopefully that gives you guys some good info to hunt this bug.

dc42

Thanks for pinning it down. I think I see what is happening. RRF detects layer changes by looking for movement involving both XY and E while at a height that is greater than the previous such height. So it's the combination of the G1 Z60 move and the following G1 X20 Y20 E-4 move that causes RRF to think there has been a layer change, and the new layer is at Z=60.

I can fix this particular case by requiring the extrusion to be positive, so that the G1 X20 Y20 E-4 move won't count. I will make that change in RRF 3.2beta2 which we expect to release on Monday or Tuesday.

CCS86

@dc42

Sweet, teamwork!