Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login
    1. Home
    2. Groups
    3. administrators
    Group Details Private

    administrators

    Member List
    droftartsundefined droftarts
    Phaedruxundefined Phaedrux
    yasasundefined yasas
    chrishammundefined chrishamm
    dc42undefined dc42
    T3P3Tonyundefined T3P3Tony
    • RE: M425: Backlash compensation has no effect

      I don't suppose you could update to 3.5.4 to test, or the recently released 3.6 release candidate?

      posted in Tuning and tweaking
      Phaedruxundefined
      Phaedrux
    • RE: G30 during G28 issue

      @Leonard03 Are you still using RRF 3.6.0-rc3+2 firmware?

      Ian

      posted in My Duet controlled machine
      droftartsundefined
      droftarts
    • RE: G30 during G28 issue

      @Leonard03 Okay, thanks for testing! Back to the drawing board...

      Ian

      posted in My Duet controlled machine
      droftartsundefined
      droftarts
    • RE: G30 during G28 issue

      @Leonard03 We are homing in on a bug, related to applying the skew compensation when axes are homed at the same time. In 3.5.4, this worked correctly, but now doesn't seem to.

      The difference is in how the skew compensation is applied. "resurrect-prologue.g" needs to run just X and Y homing, it runs home X, then home Y. Skew compensation is applied to X once Y is homed. In homeall.g, X and Y are homed at the same time, but doesn't seem to apply skew compensation until after the first move, which is when the axes move to resume the print, so will be in the wrong place.

      A workaround for now is to modify your homeall.g so it homes X, then Y, rather than both at the same time. Either replace the X and Y homing lines with the lines from homex.g and homey.g, or as @fcwilt mentioned earlier in this thread, replace them by calling the homex.g and homey.g macros, eg

      M98 P"homex.g"
      M98 P"homey.g"
      

      Then it should resurrect in the same place. @dc42 is working on a fix.

      Ian

      posted in My Duet controlled machine
      droftartsundefined
      droftarts
    • RE: M915: Configure motor stall detection

      @R006 stall detection is not relevant to detecting open-load conditions, however the driver-warning.g file should catch it if you are running a sufficiently recent version of RRF.

      posted in Using Duet Controllers
      dc42undefined
      dc42
    • RE: Is it safe to use spindle ground for a probe?

      @Alijambo73 your PSU DC out negative terminal should be connected to VIN- on the Duet, so it makes no difference.

      posted in Duet Hardware and wiring
      dc42undefined
      dc42
    • RE: [3.6.0-rc.3] sticky probe with 1HCL board

      @ironhydroxide did you have a chance to try this build? We plan to release 3.6.0-stable this week and I would like to include a fix for this issue in it.

      posted in Beta Firmware
      dc42undefined
      dc42
    • RE: G30 during G28 issue

      @Leonard03 please post your resurrect.g file (after pausing) and your resurrect-prolog.g file.

      posted in My Duet controlled machine
      dc42undefined
      dc42
    • RE: G30 during G28 issue

      @Leonard03 Thanks for your continued testing. Was the calibration cube on the right caused by a pause/resume, or by a "power failure" (please explain how you did this!)?

      I've just been testing this too, and find that I was able to provoke the bug when using G30 and skew compensation in 3.6.0-rc.3, but that it works correctly in 3.6.0-rc.3+1.

      With one bug resolved, I think there's something else going on when you pause and/or 'simulate a power failure', then resume/resurrect. It would seem that skew compensation is not applied, or the position is reset. When a print is paused, or there is a power failure, RRF creates a 'resurrect.g' file in the /sys folder, which is then used to return the tool to the correct position a resume the job. It could be that it is not applying skew compensation at the correct point during this.

      Could you:

      1. Start a print normally.
      2. Pause the print, or 'simulate a power failure'
      3. Send M556 to show the current skew compensation setting
      4. Copy the 'resurrect.g' file from /sys and post it
      5. resume the print and see if it shifts
      6. Post your pause.g, resume.g and the output of M556 (in case it has changed, or isn't being applied any longer)

      Thanks!

      Ian

      posted in My Duet controlled machine
      droftartsundefined
      droftarts
    • RE: Duet 3 Dimensions

      @DocTrucker yes it's the connector block will update when I next get a chance

      posted in Duet Hardware and wiring
      T3P3Tonyundefined
      T3P3Tony