Duet does not see the layer thickness

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