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

    [Feature Request] G32 Ran Flag

    Scheduled Pinned Locked Moved
    Firmware wishlist
    3
    5
    243
    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.
    • jay_s_ukundefined
      jay_s_uk
      last edited by

      It would be helpful if there was a flag in the object model that was flagged as true when G32 has been ran and completed and flagged false when M84 or M18 is ran (but not when the Z axis is homed).
      This would allow G32 to be skipped if its already been completed.
      Klipper already has a similar feature.

      Owns various duet boards and is the main wiki maintainer for the Teamgloomy LPC/STM32 port of RRF. Assume I'm running whatever the latest beta/stable build is

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

        @jay_s_uk G32 just runs bed.g, you're free to configure that yourself. If you just want to know if mesh compensation is active, check out move.compensation.type.

        Duet software engineer

        jay_s_ukundefined 1 Reply Last reply Reply Quote 0
        • jay_s_ukundefined
          jay_s_uk @chrishamm
          last edited by

          @chrishamm I know G32 runs bed.g. I could create a global value that runs but theres no way of clearing that when running M18 or M84 independently.
          This is for gantry levelling and not mesh compensation
          Here is the link the klipper documentation https://www.klipper3d.org/Status_Reference.html#quad_gantry_level

          Owns various duet boards and is the main wiki maintainer for the Teamgloomy LPC/STM32 port of RRF. Assume I'm running whatever the latest beta/stable build is

          1 Reply Last reply Reply Quote 0
          • jay_s_ukundefined
            jay_s_uk
            last edited by

            Thinking about this a little more. Maybe the answer would be to extend M84 to run something like motors_off.g if it exists. That would give a lot more flexibility, especially around stepper motor brakes etc. Any parameters passed through could also be used too.

            Owns various duet boards and is the main wiki maintainer for the Teamgloomy LPC/STM32 port of RRF. Assume I'm running whatever the latest beta/stable build is

            1 Reply Last reply Reply Quote 2
            • Herniczundefined
              Hernicz
              last edited by

              You can write a code in daemon.g that would clear the global variable for you if your axes aren't homed (which would happen in you disable motors or idle hold anyway)

              The only thing is that you might need to put the code in a while loop in daemon.g so the variable get cleared faster (daemon.g has some delay, that you can lower with a while loop)

              Be aware, when you home an axis it gets "un"homed during a homing sequence, therefore you need to set up additional variables to prevent your G32 global variable get cleared when you home an axis that was already homed.

              There are known knowns and known unknowns, things we know that we don't know. But there are also unknown unknowns.

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