[3.1.1] Issue Parsing Layer Change



  • For some reason DWC / RRF is having a hard time parsing layer changes from Cura generated code.

    It has been working fine for me in Cura 4.6.1, so I assumed it was something introduced in 4.6.2. I looked at the gcode and noticed that layer change line also included redundant XY coordinates (reasserting the current position). But I fired up 4.6.1 and the format is the same. So, I'm not sure what has changed for this to stop working.

    Not sure if it is related, but, the filament usage based time estimate has been blank, even though the filament usage and total appear to be correct.

    Here is some gcode:

    test 4.6.1.gcode


  • Moderator

    Just to confirm, this is RRF3.1.1 and DWC3.1.1? Is this on a Duet3 with SBC?
    Do you also have an example of gcode that worked before?



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

    Just to confirm, this is RRF3.1.1 and DWC3.1.1? Is this on a Duet3 with SBC?
    Do you also have an example of gcode that worked before?

    This is on a Duet Maestro, running RRF3.1.1 and DWC3.1.1.

    It's actually a little more strange. When I print the files, the issue is present. But, if I simulate the same file, everything works normally. Here are some screenshots:

    5b5fde70-cfc3-4c4e-9cfd-d5847150861c-image.png

    eb5ce49f-96ea-4002-bd3a-902bebb7ec73-image.png


  • Moderator

    ;FLAVOR:Marlin

    Checking your gcode file again I notice that you have Cura set to marlin gcode flavor. Change that to reprap. In the printer profile. Cura may be inserting some unsupported gcodes that could be confusing things.

    Simulation behaves a bit differently than normal printing, so that's an interesting observation.



  • Good eye! I'm not sure what happened there. My printer has always been set to Reprap flavor. That was just a test export, and maybe Cura reverted the setting.

    I just double checked the latest gcode file BBT32.gcode and it was definitely set to reprap.

    Here is the file, zipped. Just remove the txt extension and extract.

    BBT32.zip.txt



  • Any updates on this guys?

    @dc42 @Phaedrux

    The issue persists.


  • Moderator

    Does it still happen if you don't use the leveling mesh optimizer?>
    M557 X26.118:63.254 Y51.314:88.450 S10.000 ; Leveling mesh defined by LevelingMeshOptimizer



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

    Does it still happen if you don't use the leveling mesh optimizer?>
    M557 X26.118:63.254 Y51.314:88.450 S10.000 ; Leveling mesh defined by LevelingMeshOptimizer

    Are you saying without an M557 command at all? I have not tried that. Could mesh leveling really bork DWC's layer parsing?


  • Moderator

    I mean without running the preparser. Perhaps it's changing more than expected.


  • Moderator

    ;FLAVOR:RepRap
    ;TIME:2524
    ;Filament used: 0.926325m
    ;Layer height: 0.15
    ;MINX:26.118
    ;MINY:51.314
    ;MINZ:0.2
    ;MAXX:63.254
    ;MAXY:88.45
    ;MAXZ:12.65
    ;POSTPROCESSED
    ;Generated with Cura_SteamEngine 4.6.2
    T0
    M82 ;absolute extrusion mode
    
    
    ;//////// START GCODE \\\\\\\\
    
    
    G90                                          ; abs pos
    M82                                          ; abs ext
    M106 S0                                      ; fan off
    
    
    
    M104 S170                                    ; Set hotend
    M140 R35     ; Set bed
    
    G28                                          ; Home
    
    M109 S170                                    ; Wait for hotend
    M190 R35     ; Wait for bed
    
    
    M557 X26.118:63.254 Y51.314:88.450 S10.000 ; Leveling mesh defined by LevelingMeshOptimizer
    G29 S0                                       ; Load bed mesh
    M376 H3                                      ; Mesh taper
    
    G1 Z60.0 F5000                               ; Lift
    G92 E0                                       ; Zero extruder
    G1 X20 Y20 E-4 F4000
    
    M109 S220   ; Wait for hotend
    
    G1 X10 Y0 Z.3 F2000
    G1 E0 F2000
    G1 X50 E5 F1200
    G1 X140 E11 F1200
    G1 Y2 Z.1 F9000
    G4 S2
    G1 Y3 F9000
    G1 X20 Z.07 F9000
    G1 Z5 ;E
    
    G92 E-.7                                      ; Comp for ooze
    
    
    ;///////////////\\\\\\\\\\\\\\
    G92 E0
    G92 E0
    G1 F2100 E-2
    ;LAYER_COUNT:84
    ;LAYER:0
    M107
    G0 F4533.3 X34.449 Y54.369 Z0.2
    ;TYPE:SKIRT
    G1 F2100 E0
    G1 F1200 X34.867 Y54.114 E0.00614
    G1 X35.321 Y53.931 E0.01228
    G1 X35.799 Y53.824 E0.01842
    G1 X36.288 Y53.796 E0.02456
    G1 X36.5 Y53.819 E0.02724
    G1 X36.584 Y53.667 E0.02942
    

    You've also got this big Z move in there

    G1 Z60.0 F5000 ; Lift

    Maybe add a ;E after that one as well.



  • @Phaedrux

    Does ;E have any special function? I thought DWC was just ignoring Z moves that had any comment attached.


  • Moderator

    It will ignore any G1 Z moves that have an extrusion parameter with them. That's why adding the ;E is a thing.

    Another way around it is to place any start and end scripting in the start.g and stop.g files. Start.g gets run before the sliced gcode file starts, so you can move a lot of the prep there. And stop.g gets called by M0 which you would put in the slicer end gcode.



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

    It will ignore any G1 Z moves that have an extrusion parameter with them. That's why adding the ;E is a thing.

    Another way around it is to place any start and end scripting in the start.g and stop.g files. Start.g gets run before the sliced gcode file starts, so you can move a lot of the prep there. And stop.g gets called by M0 which you would put in the slicer end gcode.

    Cool, I might move my start/stop stuff there just to clean things up. I would only put M0 in my slicer end gcode?

    The thing that sticks out to me is that when I simulate the same file it tracks layers just fine. If it was just syntax of my gcode, how could this happen?


  • Moderator

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

    I would only put M0 in my slicer end gcode?

    If you want. M0 will call stop.g so if you want to move all your end gcode into there you can.



  • Hmmm, I was looking at moving my start gcode, but realized I rely on the slicer's ability to pass bed and hotend temps into that code, so it doesn't seem practical to do so.


  • Moderator

    That's still doable, but may require splitting your start stuff into two sections. Here's what I do to preserve the slicer temp settings.

    Start.g contains the print prep. Then passes off to the slicer for temp settings. And then a macro is called to do a prime line once temps are reached.

    M106 P2 F15000 L0.1 X0.8 B0.5 T25:40 H100:101:102 C"Duet Fans"
    M106 P0 F100 S0 H-1 B0.5 C"Part Cooling"                             ; Set fan 0 (Part cooling blower) G-code controlled. Thermostatic control is turned off
    M140 S65		; set heated bed to 65 and release
    T0			; Select Tool 0
    M291 P"Print Started. Preheating and Homing." T10
    G4 S1
    M98 P"0:/macros/Musical Tunes/LuckyTune.g" ; Lucky tune to start print off on the right foot
    G4 S1
    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
    M106 S0			; Turn part cooling blower off if it is on
    G10 P0 R0 S80		; Set extruder to 80 and release
    M190 S65		; set heated bed to 65 and wait
    G28			; home XYZ
    G29 S1			; load heightmap
    M400
    G10 P0 R80 S180	; Set extruder to 180 and release
    M98 P"0:/sys/ZSpeedsPrint.g"	; Load Z speeds for printing
    M98 P"0:/sys/CurrentsPrint.g"	; Load print motor currents
    ; Slicer Start Gcode begins.
    
    ; Prusa slic3r start gcode
    ; note that bed temp is inserted before this by the slicer since I haven't tried to define it here.
    M109 S[first_layer_temperature]	; Set extruder to first layer temp and wait
    G10 P0 R100 S[first_layer_temperature]  ; set temp and standby temp
    M116 ; wait for temps
    G28 Z
    M98 P"0:/sys/PrimeNozzle.g"
    
    ;M98 P"0:/sys/PrimeNozzle.g"
    G90 			; Absolute positioning
    G1 X1 Y270 F6000 	; Move to front left corner
    M400 			; clear movement buffer
    M116 			; Wait for temps
    G1 Z0.3 F100		; Move Z to prime height
    G91 			; Relative positioning
    M83 			; Relative extrusion
    G1 E5 F300 ; pre-prime nozzle
    G1 X40 E10 F300 	; Prime line
    G10			; Retract
    G1 Y-1 X1 F10000 	; Wipe nozzle
    M400
    


  • 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.


  • Moderator

    65ecb416-4221-422e-9eae-f20167c9ba1e-image.png Screen Shot 2020-09-23 at 9.49.02 PM.png

    Here's what I get with a DuetWifi fw and DWC 3.1.1 sliced with Super Slicer. Again, I don't have any gcode commands in my start gcode section other than calling a macro and M0 at the end.

    I suggest trying to reflash your firmware and DWC version.

    Download this zip file and upload it as is to the sys folder. Don't extract it.

    https://github.com/Duet3D/RepRapFirmware/releases/download/3.1.1/Duet2and3Firmware-3.1.1.zip



  • Tried that, but it still doesn't seem to be working:

    32b635cb-d457-4a66-a498-ea77ac1b9ed6-image.png

    It always seems to know the correct total layer count. It always seems to start at "layer 2". There seems to be an arbitrary time associated with this starting layer.


  • Moderator

    Have you tried migrating to using start.g and stop.g yet?



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

    Have you tried migrating to using start.g and stop.g yet?

    Not yet. But with this version RRF and DWC it was working fine in the past. I'm not sure if some subtle tweak to the start gcode broke it, or what.

    It would be awesome if a dev could run through debug with the gcode I posted. Maybe it is getting tripped up on something we haven't noticed.

    The only thing I can think of that I changed, is putting a larger SD card in. But, I am unsure if it was before/after layer parsing broke,.


  • Moderator

    @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?



  • ;//////// 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
    
    ;////////////\\\\\\\\\\\\
    


  • 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
    
    ...
    
    


  • 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.


Log in to reply