[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? -
@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:
-
;FLAVOR:MarlinChecking 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.
-
-
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 LevelingMeshOptimizerAre you saying without an M557 command at all? I have not tried that. Could mesh leveling really bork DWC's layer parsing?
-
I mean without running the preparser. Perhaps it's changing more than expected.
-
;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.02942You've also got this big Z move in there
G1 Z60.0 F5000 ; Lift
Maybe add a ;E after that one as well.
-
Does ;E have any special function? I thought DWC was just ignoring Z moves that had any comment attached.
-
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?
-
@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.
-
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.
-
Screen Shot 2020-09-23 at 9.49.02 PM.pngHere'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:
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.
-
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,.
