Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login

    Duet does not see the layer thickness

    Scheduled Pinned Locked Moved
    Tuning and tweaking
    5
    21
    729
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • Plohishundefined
      Plohish
      last edited by Plohish

      Can you please tell me why me Duet does not see the layer thickness in the code and does not count the number of layers and height?
      visota.gcode

      Please forgive my bad English, it's Google's fault :)

      1 Reply Last reply Reply Quote 0
      • achrnundefined
        achrn
        last edited by achrn

        Where are you not seeing it? If I simulate your gcode on my RRF 3.4.2 machine I do get a layer chart that is counting layers:
        fa71c22c-fd6d-41a7-95a1-a1264e26f238-image.png

        I don't get layer height in the jobs list:
        eb0d0cec-4206-4c4a-8083-49bdd13dfd2d-image.png
        and that looks like a translation issue, possibly in post-processing: in the comments block at the end of the file (line 19676) the comment line that would normally read ; layer_height = <whatever> reads ; layer_visota = 0.2. I'm guessing RRF looks for a 'layer_height' line for information for the file list.

        If that line is changed back to 'layer_height' the information is shown in the job list.

        I think it might be post-processing issue because you also have a line ; post_process = "d:\\Install\\3D_Printer_UNI\\script\\gsar.exe -s\" layer_visota\" -r\" layer_visota\" -o" I'm guessing either you or the author of your postprocessing speaks Bulgarian ('visota' being Bulgarian for height, apparently).

        1 Reply Last reply Reply Quote 2
        • Plohishundefined
          Plohish
          last edited by

          Thank you for the answer. Im not Bulgarian 🙂
          Yes, I specifically replaced the expression "layer_height" in the code with "layer_visota"
          Prusaslicer inserts an erroneous value 0.2 instead of 0.1 into the code(layer_height = 0.2). I wanted to rule it out.
          ds42 wrote that the Duet is looking for the first mention of the G1 Z code, and based on this, it concludes about the thickness of the layer and the height of the product, why is this not happening?

          Please forgive my bad English, it's Google's fault :)

          achrnundefined 1 Reply Last reply Reply Quote 0
          • achrnundefined
            achrn @Plohish
            last edited by

            @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.
            f2fc889c-9429-4e99-8a2f-ce41fe6eae6c-image.png

            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.

            Plohishundefined 1 Reply Last reply Reply Quote 0
            • Plohishundefined
              Plohish @achrn
              last edited by

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

              Please forgive my bad English, it's Google's fault :)

              oliofundefined 1 Reply Last reply Reply Quote 0
              • oliofundefined
                oliof @Plohish
                last edited by

                @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 (-:

                <>RatRig V-Minion Fly Super5Pro RRF<> V-Core 3.1 IDEX k*****r <> RatRig V-Minion SKR 2 Marlin<>

                Plohishundefined 1 Reply Last reply Reply Quote 0
                • Plohishundefined
                  Plohish @oliof
                  last edited by

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

                  Please forgive my bad English, it's Google's fault :)

                  oliofundefined 1 Reply Last reply Reply Quote 0
                  • oliofundefined
                    oliof @Plohish
                    last edited by

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

                    <>RatRig V-Minion Fly Super5Pro RRF<> V-Core 3.1 IDEX k*****r <> RatRig V-Minion SKR 2 Marlin<>

                    Plohishundefined 1 Reply Last reply Reply Quote 0
                    • Plohishundefined
                      Plohish @oliof
                      last edited by

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

                      Please forgive my bad English, it's Google's fault :)

                      achrnundefined 1 Reply Last reply Reply Quote 0
                      • achrnundefined
                        achrn @Plohish
                        last edited by

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

                        Plohishundefined 1 Reply Last reply Reply Quote 0
                        • Plohishundefined
                          Plohish @achrn
                          last edited by 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
                          777787.JPG

                          Please forgive my bad English, it's Google's fault :)

                          achrnundefined 1 Reply Last reply Reply Quote 0
                          • achrnundefined
                            achrn @Plohish
                            last edited by

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

                            Plohishundefined achrnundefined 3 Replies Last reply Reply Quote 0
                            • Plohishundefined
                              Plohish @achrn
                              last edited by 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

                              Please forgive my bad English, it's Google's fault :)

                              1 Reply Last reply Reply Quote 0
                              • Plohishundefined
                                Plohish @achrn
                                last edited by

                                @achrn i made pictures

                                3333.jpg

                                555557.png

                                Please forgive my bad English, it's Google's fault :)

                                droftartsundefined 1 Reply Last reply Reply Quote 0
                                • droftartsundefined
                                  droftarts administrators @Plohish
                                  last edited by

                                  @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

                                  Bed-slinger - Mini5+ WiFi/1LC | RRP Fisher v1 - D2 WiFi | Polargraph - D2 WiFi | TronXY X5S - 6HC/Roto | CNC router - 6HC | Tractus3D T1250 - D2 Eth

                                  Plohishundefined 1 Reply Last reply Reply Quote 0
                                  • Plohishundefined
                                    Plohish @droftarts
                                    last edited by

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

                                    Please forgive my bad English, it's Google's fault :)

                                    droftartsundefined chrishammundefined 2 Replies Last reply Reply Quote 0
                                    • droftartsundefined
                                      droftarts administrators @Plohish
                                      last edited by

                                      @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

                                      Bed-slinger - Mini5+ WiFi/1LC | RRP Fisher v1 - D2 WiFi | Polargraph - D2 WiFi | TronXY X5S - 6HC/Roto | CNC router - 6HC | Tractus3D T1250 - D2 Eth

                                      1 Reply Last reply Reply Quote 0
                                      • chrishammundefined
                                        chrishamm administrators @Plohish
                                        last edited by

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

                                        Duet software engineer

                                        1 Reply Last reply Reply Quote 0
                                        • Plohishundefined
                                          Plohish
                                          last edited by

                                          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

                                          Please forgive my bad English, it's Google's fault :)

                                          1 Reply Last reply Reply Quote 0
                                          • achrnundefined
                                            achrn @achrn
                                            last edited by

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

                                            Plohishundefined 1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Unless otherwise noted, all forum content is licensed under CC-BY-SA