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

New Edge firmware 1.18beta2

Scheduled Pinned Locked Moved
Firmware installation
5
12
1.8k
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.
  • undefined
    BlackTom
    last edited by 15 Mar 2017, 14:53

    David,
    I have an issue with this firmware version on my coreXY.

    When I move my axes (X, Z and Y) everything looks fine

    When I execute homeall it seems that the endstop logic is reversed or something else, i'm not able to home. I revedted to beta1 and it's fine.

    Thanks

    1 Reply Last reply Reply Quote 0
    • undefined
      hairy_kiwi
      last edited by 15 Mar 2017, 15:57

      @blood3D - I have no suggestions, sorry, but FWIW; I have a Cartesian Mendel90-style printer and my homeall.g and homez.g macros are working the same on 1.18beta2 as they were on 1.18beta1.

      Here's mine:

      ; homeall.g
      G91
      G1 Z5 F200 ; raise head 5mm to keep it clear of the bed
      G1 X240 Y-240 F3000 S1 ; coarse home X and Y
      G1 X-4 Y4 F200 ; move 4mm away from the homing switches
      G1 X10 Y-10 S1 ; fine home X and Y
      G90
      G1 X66 Y85 F3000 ; IMPORTANT: move to a bed mesh grid point - to prevent chance of Z0 height-interpolation error.
      G30
      ;G1 X0 Y0 Z0.05 F5000
      G0 X100.0 Y5.0 Z0.05 F5000 ; move tool to midway along front of bed to position for initial prime/wipe move
      1 Reply Last reply Reply Quote 0
      • undefined
        dc42 administrators
        last edited by 15 Mar 2017, 19:48

        @bloood3d:

        David,
        I have an issue with this firmware version on my coreXY.

        When I move my axes (X, Z and Y) everything looks fine

        When I execute homeall it seems that the endstop logic is reversed or something else, i'm not able to home. I revedted to beta1 and it's fine.

        Thanks

        Strange, there have been no intentional changes in that area. Please confirm that you have not changed your homeall.g file. You could also try running the commands in the homeall.g file one at a time to see what happens.

        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
        • undefined
          sigxcpu
          last edited by 15 Mar 2017, 19:51

          Unless it is something that I am missing, CoreXY homing is broken in this version.

          If I try to home X, Y moves randomly. If I try to home Y, X moves randomly.

          Works as expected on 1.17e.

          homex.g

          G91 ; relative mode
          G1 S1 X-300 F3000 ; course home X
          G1 X4 F600 ; move away from the endstops
          G1 S1 X-10 ; fine home X
          G90

          homey.g

          G91 ; relative mode
          G1 S1 Y-300 F3000 ; course home Y
          G1 Y4 F600 ; move away from the endstops
          G1 S1 Y-10 ; fine home Y
          G90
          1 Reply Last reply Reply Quote 0
          • undefined
            dc42 administrators
            last edited by 15 Mar 2017, 20:52

            OK, I can guess what happened. I made a change to not apply bed compensation during homing moves, and perhaps it also disabled CoreXY motor mapping. I'll look at it tomorrow morning. I'm sorry for the inconvenience.

            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
            • undefined
              tomasf
              last edited by 15 Mar 2017, 22:53

              Maybe I'm missing something, but I can't seem to get babystepping to work. Nothing seems to happen when I do a [c]M290 S0.05[/c], regardless of the value of S. No motor movement. If I query it with [c]M290[/c], I get bogus values:

              M290
              Baby stepping offset is 000
              M290 S1.0
              M290
              Baby stepping offset is -1073741824
              M290 S0.05
              M290
              Baby stepping offset is 1610612736

              Everything else seems to work fine. I'm using my Kossel XL-style printer.

              1 Reply Last reply Reply Quote 0
              • undefined
                dc42 administrators
                last edited by 16 Mar 2017, 03:46

                M290 does not cause movement itself, but it modifies future movement. It has a limit of 1mm at a time. I'll check out the behaviour of M290 with no parameters.

                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
                • undefined
                  tomasf
                  last edited by 16 Mar 2017, 07:00

                  @dc42:

                  M290 does not cause movement itself, but it modifies future movement. It has a limit of 1mm at a time. I'll check out the behaviour of M290 with no parameters.

                  Oh, I see. Yeah, looking at the source code, I'm guessing it should be [c]%.3f[/c] instead of [c]%.3d[/c] for the printf. 🙂 rr_status reports the correct babysteps.

                  Perhaps I'm still not getting how this works. If I do a couple of dozen [c]M290 S1.0[/c], there should be a very noticeable jump in Z next time I move X/Y, right? Z doesn't seem to move at all.

                  1 Reply Last reply Reply Quote 0
                  • undefined
                    BlackTom
                    last edited by 16 Mar 2017, 15:59

                    Thank you guys.. I report that I've the same behavior for m290. I guess tomasf explaination make sense

                    1 Reply Last reply Reply Quote 0
                    • undefined
                      dc42 administrators
                      last edited by 16 Mar 2017, 17:01

                      @tomasf:

                      Perhaps I'm still not getting how this works. If I do a couple of dozen [c]M290 S1.0[/c], there should be a very noticeable jump in Z next time I move X/Y, right? Z doesn't seem to move at all.

                      The amount of babystepping that is applied to each XY move is limited so that the change in Z speed needed is somewhat less than the Z jerk speed. So if you apply abnormally large amounts of babystepping, it may take a lot of XY moves to catch up. Babystepping is intended for use with small adjustments, typically less than 0.1mm.

                      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
                      • undefined
                        dc42 administrators
                        last edited by 16 Mar 2017, 18:33

                        Those of you having issues with 1.18beta 2, please try 1.18beta3 and continue the discussion in the thread about that release.

                        https://www.duet3d.com/forum/thread.php?id=1115

                        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
                        10 out of 12
                        • First post
                          10/12
                          Last post
                        Unless otherwise noted, all forum content is licensed under CC-BY-SA