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

    [3.4.6+SBC] DWC - "Object Height" issue/bug?

    Scheduled Pinned Locked Moved Solved
    Duet Web Control
    5
    13
    360
    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.
    • SJIundefined
      SJI @oozeBot
      last edited by

      @oozeBot I've noticed the same with simplify 3d v5 lately on rrf 3.5rc2. Not all gcode files but a few. I thought initially it was S3D causing it

      1 Reply Last reply Reply Quote 0
      • Phaedruxundefined
        Phaedrux Moderator
        last edited by

        Is it only happening on files larger than 25mb?

        Z-Bot CoreXY Build | Thingiverse Profile

        oozeBotundefined 1 Reply Last reply Reply Quote 0
        • oozeBotundefined
          oozeBot @Phaedrux
          last edited by

          @Phaedrux No - our test deck has some very large files that work just fine.. we haven't pinpointed what's causing it, but it appears to have something to do with multiple objects.

          8f0ea41a-decf-4da3-91ba-e542b72a5d59-image.png

          OwenDundefined 1 Reply Last reply Reply Quote 0
          • OwenDundefined
            OwenD @oozeBot
            last edited by

            @oozeBot
            I can more or less reliably replicate this, however it seems more related to file size than to the number of instances.
            These are mostly all the same parts, just with varying instances to achieve different file sizes.
            I also did a couple of large parts with a single instance.
            At around 25-29MB, I get a height of zero with the multiple instance files.
            This suggests RRF/DWC might stop parsing the file looking for the height after this.
            But with the single instance files, it was much higher.
            The boxes are the same size with differing infill percentage.

            I wonder if your larger files have already been printed or simulated?
            Did they have thumbnails?

            For reference I'm running
            Duet 2 WiFi 2WiFi 3.5.0-rc.2
            Duet Web Control DWC 3.5.0-rc.2
            Prusa Slicer 2.7.1+

            height.png

            1 Reply Last reply Reply Quote 1
            • oozeBotundefined
              oozeBot
              last edited by

              That huge file in the screenshot that is over 500MB was uploaded moments before I took the screenshot - Object Height reads just fine. So it's definitely a head scratcher..

              @dc42 - any insight as to what is going on or what RRF uses to calculate Object Height? FYI - our slicer profile already injects the following in the "End G-Code" section as suggested in several other threads.

              ;NUM_LAYERS [layer_num]
              
              chrishammundefined 1 Reply Last reply Reply Quote 0
              • chrishammundefined
                chrishamm administrators @oozeBot
                last edited by

                @oozeBot NUM_LAYERS has nothing to do with object height detection and in SBC mode, RRF doesn't parse G-code file info either - that's done by DSF in this case. And DSF looks for the last absolute G0/G1 Z parameter, which is then returned as the object height.

                I'd need to see your full end G-code to tell you what's wrong. Maybe you lift Z at the end but don't switch back to absolute mode as in

                G91 ; relative mode
                G1 Z5 ; lift Z by 5mm
                G90 ; absolute mode
                

                Duet software engineer

                oozeBotundefined 1 Reply Last reply Reply Quote 0
                • oozeBotundefined
                  oozeBot @chrishamm
                  last edited by

                  @chrishamm

                  Here is the ending gCode (minus comments) for one of the files which fails to parse Object Height. The routine which runs after the job is complete is encapsulated in the custom mCode M9001.

                  Perhaps it has to do with M486? I believe that was introduced as a feature in PrusaSlicer 2.7.1?

                  I can provide a full file if necessary.

                  G1 X263.999 Y139.759 F12000
                  G1 F6000
                  G1 X260.696 Y143.062 E.21742
                  G1 X260.707 Y142.418 F12000
                  G1 F6000
                  G1 X263.354 Y139.77 E.17427
                  G1 X262.488 Y140.003 F12000
                  G1 F6000
                  G1 X260.949 Y141.542 E.1013
                  M486 S-1
                  G10 ; retract
                  M9001
                  ;TYPE:Custom
                  
                  chrishammundefined 1 Reply Last reply Reply Quote 0
                  • chrishammundefined
                    chrishamm administrators @oozeBot
                    last edited by

                    @oozeBot It might be that your last true G1 Znnn command is too far in the file and DSF just gives up before it is reached - this can happen if your last layer is really long. In that case I suppose you could work-around it by inserting a custom G1 Z{layer_z} code right at the end using PrusaSlicer. That new G1 Z move should then be ignored by RRF but it should be picked up by DSF for the object height detection.

                    I haven't tested it yet but it should work.

                    Duet software engineer

                    oozeBotundefined 2 Replies Last reply Reply Quote 0
                    • oozeBotundefined
                      oozeBot @chrishamm
                      last edited by

                      @chrishamm This makes sense and is likely the culprit.. The last layer change on this file is at line 2013568. The last line in the file is 2034064. That's a bit over 20000 lines and I bet it is scanning way less than that.

                      oozeBotundefined 1 Reply Last reply Reply Quote 0
                      • oozeBotundefined
                        oozeBot @chrishamm
                        last edited by

                        @chrishamm Placing a G1 Zxx.xx at the very end of the file fixes the issue. While I understand this won't affect the machine's travel, I'm not thrilled with this being the solution.

                        Perhaps a marker could be added similar to NUM_LAYERS which, when present, would populate the Object Height without further scanning of the file?

                        1 Reply Last reply Reply Quote 0
                        • oozeBotundefined
                          oozeBot @oozeBot
                          last edited by oozeBot

                          @chrishamm - thanks for the nudge on where this is parsed. We were on the fence about building custom versions of DSF (we wanted to keep these stock), but for now, we went ahead and rebuilt for publishing on our package server.

                          What we did was added a new custom parameter that can be added into the End G-Code section:

                          ;TYPE:Custom
                          ; OBJ_HEIGHT: 24.23
                          

                          which results in:
                          c118bc4d-2c31-450d-871f-8c9ebfe52555-image.png

                          chrishammundefined 1 Reply Last reply Reply Quote 0
                          • oozeBotundefined oozeBot has marked this topic as solved
                          • chrishammundefined
                            chrishamm administrators @oozeBot
                            last edited by

                            @oozeBot Looks good, feel free to send me a PR for this!

                            Duet software engineer

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