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

    Excluding regions where the tool should not go

    Scheduled Pinned Locked Moved
    General Discussion
    5
    9
    908
    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.
    • ephemerisundefined
      ephemeris
      last edited by ephemeris

      I have a printer with a rectangular print region. I park the carriage outside the printable area. I use M208 to extend the travel range in Y so that the parking area is reachable. The problem is that when in the parking area, a bad X command could push the tool into an area it should not go causing a carriage crash.

      Long story short, it would be nice (and safer) if there was a way to describe the legal travel range as something other than a simple rectangle. I skimmed through the current gcode documentation and don't see a way to do this.

      Is it currently possible to do a non-rectangular region or is this a wish-list item?

      1 Reply Last reply Reply Quote 0
      • aidarundefined
        aidar
        last edited by

        I would do it with macro. In config i would define travel range as safe print area, for parking use macro to redefine Y and X axis so X can move only in safe area. Before new print restore defaults with another macro.

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

          When you say you redefine M208, how do you do that? Typically when you have the parked position outside the bed area you would use a negative value for the M208 axis minima, which keeps 0,0 on the corner of the bed. This way any travel moves are going to be into the positive area and should help avoid your issue.

          Z-Bot CoreXY Build | Thingiverse Profile

          1 Reply Last reply Reply Quote 0
          • ephemerisundefined
            ephemeris @aidar
            last edited by

            @aidar I agree this could work by adding startup gcode in Simplify3d to restore the limits at the beginning of the print. Of course that just means there's yet another bit of jiggery pokery in S3D I have to maintain.

            1 Reply Last reply Reply Quote 0
            • Jacotheronundefined
              Jacotheron
              last edited by

              @ephemeris In stead of having that restore code directly in S3D, why don't you have that in a Macro, that is simply called by your starting Gcode (https://duet3d.dozuki.com/Wiki/Gcode#Section_M98_Call_Macro_Subprogram).

              I have used this technique for my starting gcode (which was causing layer count issues).
              Basically you would call it like M98 P"0:/macros/Starting/reset" (this will call the "reset" macro inside a folder called "Starting").

              You can also use the same method to add it to your ending gcode to automatically park the head at the end of a print.

              The nice added bonus of this method is that any new sliced file will use the latest version of the macros (at the time of printing) regardless of when it is changed.

              ephemerisundefined 1 Reply Last reply Reply Quote 0
              • ephemerisundefined
                ephemeris @Jacotheron
                last edited by

                @jacotheron To be clear, you're suggesting adding the M98 to the starting gcode field in Simplify3D?

                1 Reply Last reply Reply Quote 0
                • Jacotheronundefined
                  Jacotheron
                  last edited by

                  Yes, the M98 command goes in your starting gcode at the appropriate location. It is processed as if the macro's contents was present in the starting gcode, even though it is not, and it can be updated with minimal effort.

                  ephemerisundefined 1 Reply Last reply Reply Quote 0
                  • ephemerisundefined
                    ephemeris @Jacotheron
                    last edited by

                    @jacotheron Very clever! Thanks for the tip.

                    I think a more directly supported gcode solution would be a good thing, but this gives me something to work with.

                    1 Reply Last reply Reply Quote 0
                    • dc42undefined
                      dc42 administrators
                      last edited by

                      Another way would be to use M208 to set the printable limits, and in the parking code use M564 S1 to allow movement outside those limits temporarily.

                      Duet WiFi hardware designer and firmware engineer
                      Please do not ask me for Duet support via PM or email, use the forum
                      http://www.escher3d.com, https://miscsolutions.wordpress.com

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