Duet does not see the layer thickness

achrn

@Plohish I'm not sure what you mean by "an erroneous value 0.2". In that gcode file your layer height is 0.2mm, with an extra 0.02 on the first layer (you have ; first_layer_height = 0.22). Your layers are:

line 42: G1 Z.22 F10200
line 558: G1 Z.42 F10200
line 933: G1 Z.62 F10200
etc

Your volumes look about right for 0.2mm layers. See e.g. lines 4595 & 4596 (pretty much random picks) - you travel 0.526mm, so at perfect 0.4 width and 0.2 height that's 0.0421mm3, you extrude 0.0163mm and assuming 1.75mm filament that's 0.0391mm3. That's a factor 0.929, which is 'about right', I think - it would be over-extrusion if layer height was 0.1mm.

So everything about your file looks like it's 0.2mm layer height to me.

I don't think the Duet looks for the first G1 Z and assume that applies for the whole file. You wouldn't want to do that because it's quite commonly the case that first layer is done differently (including in your file). Note that layer reportingchanged with both RRF 3.3 and 3.4 - see the release notes :
https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x#reprapfirmware-340 - "The first layer height of the file being printed is no longer reported in the object model or by M408"
https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x#reprapfirmware-33 - "RepRapFirmware no longer tries to work out what layer number is printing, and no longer provides an estimate of print completion time based on layer progress. The mechanism to work out the layer number failed in many cases, for example when the slicer used variable layer heights or printed multiple objects one at a time. The removal of these 200 lines of hard-to-maintain code has made more space available for other features on the older Duets that are tight on memory space. A consequence of this change is that DWC will no longer produce a layer chart if the GCode file being printed does not include layer number comments. For slicers that do not normally generate these comments (e.g. PrusaSlicer) it is usually possible to add a layer change script to generate them."

So if you're looking at references older than that things might be different.

Plohish

@achrn
I'm sorry if I misled you.
In the file that I posted above, everything is correct with the layer thickness, however, PrusaSlicer has a bug, the steps along the Z axis can be 0.1mm, but the Layer_height parameter will still be specified as 0.2mm
That's why I wanted to get rid of this line.
Respected @chrishamm talks about the method for determining the height of the layer at the first mention of G1 Z
*The first layer height is determined by looking for the first absolute G0/G1 ... Z code in the G-code file.
Link Wrong layer count

should this work?

oliof

@Plohish individual layer print time never was a good indicator for overall print time and individual layer thickness (and with Cura's Arachne slicer engine even width) continues to be a useless metric for gauging print process. See https://forum.duet3d.com/topic/30432/layer-chart-empty where I argue that the whole layer chart should be removed to make space for more useful information or controls (-:

Plohish

@oliof I don't want to estimate the print time, I don't see the number of layers if I remove the "layer_height" parameter from the code...

oliof

@Plohish yes, that is correct. Let me ask you why you would need to know the number of layers?

Plohish

@oliof Let me try to explain again:
Prusaslicer makes a mistake in the code, when using a 0.1mm layer, the parameter layer_height=0.2 remains in the code, in this situation the number of print layers in the Duet interface is not correct!
I want to remove the layer_height=0.2 parameter from the code using post-processing, but I also want to get the correct number of layers in the Duet interface.

achrn

@Plohish You are now talking about nuimber of layers wheras previously it was mainly about layer height.

Where in the print interface are you looking for the number of layers? Where is it showing wrong?

Everything about that file shows it to be correctly a file with 0.2 layer height, and if you edit 'visota' back to 'height' that is (apparently correctly) shown in the Duet user interface. Whether you do the edit or not, the progress chart shows the correct number of layers, as far as I can see.

(As an aside, I observe that my version of PrusSlicer (2.4.1 on Windows) generates 0.1mm layer gcode with no problem, and writes teh the value in the layer_height line at the final comment block.)

Plohish

@achrn please make a project with these settings, and check it in Duet simulation mode,
compare the number of layers given by Prusa and Duet

achrn

@Plohish OK, I've done that and I'm willing to tell you what I found if (and only if) you answer the question I've asked you variations of three times and as far as I can see, you're yet to answer:

Where in the print interface are you looking for the number of layers?
Where is it showing wrong?
Where are you not seeing it?

Plohish

@achrn sorry, I won't be near the printer right now, I can take a screenshot in the evening, but I'll try to describe it in words.
I see the wrong number of layers in the web interface, the scrolling line displays the number of printed layers, for example
layer 57 of 100

also, the web interface incorrectly displays the layer thickness

Plohish

@achrn i made pictures

droftarts

@Plohish You are editing the per-part layer height to 0.1mm, while the file, as a whole, still has layer height set to 0.3mm (in Print Settings > Layers and perimeters > Layer height). You only have one part on the bed. But if you had more parts, they would be sliced at 0.3mm. You can select different layer heights for each part, and even different layer heights within each part. RepRapFirmware bases the layer calculation on the layer set by the whole file. Once you start using per-part layer heights, and variable heights, there is no way for the RepRapFirmware to keep track of this many changes in layer height, and is, in part, why calculations based on layer count, height and time is broken as slicers get more sophisticated, and really can't be fixed. Simulating files before printing is much better way to get accurate print times.

However, it works fine if you slice everything with the same layer height. To do this, change the layer height in the Print Settings profile, not in the per-part layer height.

If you want the slicer to provide better estimates for time remaining by layer, you can add M73 commands to layer changes.

Ian

Plohish

@droftarts thanks for the clarification, I began to understand why this is happening, but I still have a question: Dear @chrishamm writes that the layer thickness can be obtained on the first received command G0 Z Why does this not work?

droftarts

@Plohish Maybe because your first layer height is still 0.32mm, even when you slice per-part at 0.1mm? I haven't checked your Gcode file to see what the first 'G0 Z' move is; most moves are output as G1 moves, so that may also cause issues. Can you link to where @chrishamm said this?

Ian

chrishamm

@Plohish AFAIR this way of layer height detection was supported in the past but it isn't supported any more, because the first G0/G1 Z command may not be identical to the actual layer height. Hence we rely on comments in the sliced file to determine the true layer height. Recent PrusaSlicer versions generate the corresponding comment automatically at the start of a G-code file (e.g. ; layer_height = 0.5).

Plohish

Now everything is in place, thanks for the explanation.
Perhaps I should write to the developer Prusaslicer, in case of placing only one part on the table and the layer thickness differs from the global settings, track the variable layer_height

achrn

@achrn said in Duet does not see the layer thickness:

@Plohish OK, I've done that and I'm willing to tell you what I found if (and only if) you answer the question I've asked you variations of three times

Hi @Plohish, sorry, I think I was in a bad mood that day.

However, looking at the thread I think you've got to a resolution. FWIW, I think it's the case that neither slicer nor Duet is wrong, in that if the file is set to 0.2mm (or whatever) layer height, but that does not mean that every layer is 0.2mm high, and if you've applied an object override to every object (including the case of there only being one object) it might be the case that no layer in the gcode is that height.

I'm not sure it makes sense for the slicer to report anything other than the general setting - the first layer is often different, and functions such as variable layer height will mean there is not necesarily one layer height even if there is only one object. It could write an average layer height into the file, but I'm not sure that's particularly useful.

For completeness, if I do as you suggest, and slice an object with one layer thickness but a modifier that changes the layer thickness on a single object, yes it slices correctly and displays what I think is correct (i.e. the overall file setting) value in the jobs list. I sliced a 30mm high object, layers set to 0.3mm, modifier setting layers to 0.1mm, and simulation has 297 layers (my first layer was still set at 0.35).

Plohish

@achrn Thank you.
Using a modifier seems more convenient to me, but if there is only one object on the table, we get the wrong G-code ...
In the future, I will only use the basic settings...