duet wifi not recognizing the first layer
I noticed this today. While printing a part, layer 10 should have been the last solid layer, and layer 11 would have started new columns on the part. In duet web control, layer 11 was the last solid layer and layer 12 started the columns. I'm using .2mm layer height. The part was 2mm before columns should have started at 2.2mm. What could be causing this issue?
What firmware version and DWC version are you running?
Firmware version 2, and DWC 1.21.1.
Give these new beta releases a try.
Is this a known problem? I have the G92 Z0.1 S2 command in my home all file. It's as if the first layer is .1mm and not recognized. Then The rest of the layers go down appropriately. The reason I say this is because the skirt and first layer seem smashed down.
It may be. There were some layer counting issues but I think those were in the 2.0 release candidates. And there was an issue with the height map impacting the home height. This latest beta resolves that last one. Do you use mesh compensation?
I don't use mesh compensation. Why?
@mlaustin6 because part of the bug was that when you cleared the height map it didn't reset the current z height causing the potential for offsets to become stacked.
OK, I'll give it a shot and report back tomorrow.
mlaustin6 last edited by mlaustin6
It did not fix the problem. Layer 1 is being mislabeled as layer 2 in print status. Also the print is 75 layers, and it is saying 76. So it's adding a plus one to the count.
Does anything in this thread sound familiar to your issue?
It doesn't sound like I have empty layers because it is showing layer 2 as the first layer (unless you assume layer 1 was the empty layer). I am using Slic3r but the original not the Prusa version. I have Simplify 3d and can test with that shortly.
It's a Slic3r issue. Simplify3d doesn't have this problem.
That's a pretty old version of slic3r. I suggest trying either the Prusa edition or the 1.3 dev release of original slic3r.
Is this something that just started happening with firmware 2.0? Or is it something that's been happening for a while and only just noticed?
Nope it’s the latest 1.3.1 Dev version. I don’t know when it started. I just know I just noticed it.
Are you using a different first layer height from the other layers? The print monitor code tries to take account of a thicker than normal first layer, but if it is failing to do that on your GCode file and you have e.g. 0.4mm first layer height and 0.2mm for the other layers, that could account for the problem.
All layers are .2. The problem does not exist in simplify3d. Slice3r shifts all the layers by 1. The layer count is correct except that the first layer is layer 2.
@mlaustin6 would you be able to post a link to a gcode file that exhibits the problem?
I deleted it but was able to restore it. I believe this is the file https://1drv.ms/u/s!Arp1EuhGgXrJsF-fizg6iFSMc11z. FYI Cura reports correct layers as well. At this point it make no difference to me as I will probably use simplify3d and cura going forward as they have coasting abilities which works great for my prints.
Do you happen to use a nozzle prime routine at the start of the print, or something like that?
You've got this before the start of the skirt:
M107 M190 S95 ; set bed temperature and wait for it to be reached M104 S245 ; set temperature G28 ; home all axes G1 Z5 F5000 ; lift nozzle ; Filament gcode M109 S245 ; set temperature and wait for it to be reached G21 ; set units to millimeters G90 ; use absolute coordinates M82 ; use absolute distances for extrusion G92 E0 G92 E0 G1 E-3.10000 F7500.00000 G92 E0 G1 Z0.100 F11700.000 G1 Z0.200 F11700.000 G1 Z0.300 F11700.000 G1 X114.337 Y119.820 F11700.000 G1 Z0.200 F11700.000 G1 E3.10000 F7500.00000
I suspect that these z moves before starting the first layer are what is confusing the Duets layer counting. Does your simplify3D start code have the same moves?
I have Slic3r set to make a 35mm skirt, but I don't do anything else. It's the same think I do for Cura or Simplify3d. Although S3D won't let you set a specific amount just number of walls.
Here is some code from S3D. It does not have those z moves. I think what is causing those z moves is the way slic3r moves the nozzle at home position. It raises it, then lowers it, then moves on the bed. S3D just goes to home and moves the nozzle in a straight shot. But even Cura raises the nozzle and then lowers it as it moves to the location on the bed. the g code flavor I am using for Slic3r is Reprap. Not sure what to say here other than deal with it if I want to use Slic3r. It's only one off. Perhaps it's an issue in Slic3r (sounds like it as other slicers don't have the problem).
M104 S245 T0
M109 S245 T0
G28 ; home all axes
G1 E-4.0000 F7500
G1 Z0.300 F1000
; process Process 50i
; layer 1, Z = 0.200
; tool H0.200 W0.480
G1 X78.828 Y144.702 F11700
G1 Z0.200 F1000
G1 E0.0000 F2250
G1 X79.445 Y144.446 E0.0273 F918
G1 X140.306 Y144.446 E2.5129
G1 X140.923 Y144.702 E2.5402
Either that's specific to the dev version of slic3r you're using or there is some additional gcode in one of the slic3r windows adding that. Check the various panes of filament settings and printer settings to see if it's adding the gcode somewhere.
I'm unable to reproduce it with either the most recent dev version of slic3r 1.3 or from the latest slic3r Prusa edition.
Have you tried the Prusa edition lately? It's really quite good. The new gcode visualizer preview is very handy.