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

    Multiple motion system

    Scheduled Pinned Locked Moved Solved
    General Discussion
    8
    69
    2.5k
    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.
    • dwuk3dundefined
      dwuk3d @dwuk3d
      last edited by dwuk3d

      @Alva Update - Just managed to get it working in 3.6.0b4 - by surrounding all references to the U axis in M596 P1 - including in the homing macro's

      M598 still not working for me though -

      plus in my case I am finding a connected Mini5+ board runs slow in 3.6.0b vs 3.5.4 - so I have left that board at 3.5.4

      jay_s_ukundefined gloomyandyundefined 2 Replies Last reply Reply Quote 0
      • jay_s_ukundefined
        jay_s_uk @dwuk3d
        last edited by

        @dwuk mixing 3.5.4 and 3.6b4 based boards, with the amount of changes that have happened between the two, is a really bad idea

        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

        dwuk3dundefined 1 Reply Last reply Reply Quote 0
        • gloomyandyundefined
          gloomyandy @dwuk3d
          last edited by

          @dwuk said in Multiple motion system:

          plus in my case I am finding a connected Mini5+ board runs slow in 3.6.0b vs 3.5.4

          Can you provide more details on that? What exactly is slow?

          dwuk3dundefined 1 Reply Last reply Reply Quote 0
          • dwuk3dundefined
            dwuk3d @gloomyandy
            last edited by

            @gloomyandy The U&V axis don't react instantly when you press the +1/+10 etc. button - there seems to be a small delay.

            Also when homing the U Axis - it is a two pass process - normally the first hit happens, the tool head immediately moves back, and then has its' second attempt, but with 3.6.0 again there is a slight delay.

            The the Mini5+ board is on 3.5.4 there is no noticeable delay.

            If there isn't any obvious answer I will make a short video at some point to demonstrate the difference.

            dwuk3dundefined jay_s_ukundefined 2 Replies Last reply Reply Quote 0
            • dwuk3dundefined
              dwuk3d @jay_s_uk
              last edited by

              @jay_s_uk Yes I am sure you are right. I am not really seeing any advantage in 3.6.0b4 over 3.5.4 at the moment - so will probably revert the whole lot back to 3.5.4 - as all 3.6.0 is unusable for me.

              jay_s_ukundefined 1 Reply Last reply Reply Quote 0
              • dwuk3dundefined
                dwuk3d @dwuk3d
                last edited by dwuk3d

                @gloomyandy Just realised this is @Alva's thread - if you look at my one you will see a lot more detail of the 'slowness' problem

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

                  @dwuk if you're doing any remapping of axes after movement in 3.5.4 that's unusable too.
                  You'll notice a difference when you come to print something as the movement code is way better in 3.6, especially pressure advance and input shaping

                  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

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

                    @dwuk the out of sync/delay issues with a mainboard in expansion mode has been fixed internally. Don't know if a build has been made available

                    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

                    dwuk3dundefined 1 Reply Last reply Reply Quote 0
                    • dwuk3dundefined
                      dwuk3d @jay_s_uk
                      last edited by

                      @jay_s_uk Great - I was imagining it was some sort of comms issue - happy to test out the fix.

                      1 Reply Last reply Reply Quote 0
                      • dwuk3dundefined
                        dwuk3d @jay_s_uk
                        last edited by

                        @jay_s_uk Yes - I am currently testing with T1 mapping U&V as X&Y in the second motion system - with the real X&Y in T0. It seems to work on 3.6.0 (with the Mini5+ on 3.5.4) - but I haven't tried that approach on a completely 3.5.4 system.

                        It is not essential that I use U&V that way - as I can fairly easily change X&Y to U&V in my post processor.

                        Alvaundefined 1 Reply Last reply Reply Quote 0
                        • Alvaundefined
                          Alva @dwuk3d
                          last edited by

                          @dwuk It was working in the 3.6.0-beta2+3 and it broke on the later versions. But i haven't tested the 3.6.0-beta4 yet though. Have you tested it?

                          dwuk3dundefined 1 Reply Last reply Reply Quote 0
                          • dwuk3dundefined
                            dwuk3d @Alva
                            last edited by

                            @Alva It works differently between 3.5.4 and 3.6.0b4 - but I have been able to get it to work - but only if I home the U axis with M596 P1, and XY within M596 P0

                            I can't actually get multi axis really working properly though - because I can't get M598 syncing to work.

                            dwuk3dundefined 1 Reply Last reply Reply Quote 0
                            • dwuk3dundefined
                              dwuk3d @dwuk3d
                              last edited by dwuk3d

                              @Alva - update - I think I have found out the cause of my M598 issue -
                              See https://forum.duet3d.com/post/352006

                              I have so far been doing most of my tests as Macros.

                              If I download the macro's and then upload them as Jobs then run them they work much better - with the M598's seeming to work correctly.

                              This also might have fixed my M595 problem (although that might be a firmware based fix).

                              Not sure if this will also have any impact on my 'axes in use' issues (that I worked around by putting M596's into my homing macro's) - but will now try running my homing and tests all using jobs rather than Macro's - so see if that sorts out any other issues.

                              1 Reply Last reply Reply Quote 0
                              • dwuk3dundefined
                                dwuk3d
                                last edited by

                                Update on 3.6.0.rc1

                                The same issue is occurring as far as I can see.

                                On 3.5.4 you can get an axis released by doing T-1 followed by M400 (or probably M598), but on 3.6.0.b4 and rc1 once you have used an AXIS in a motion system it seems to never be released- whatever combination of switching tools, motion systems, M400 and M598's I have tried.

                                Alvaundefined dc42undefined 3 Replies Last reply Reply Quote 0
                                • Alvaundefined
                                  Alva @dwuk3d
                                  last edited by

                                  @dwuk3d Thank you so much for informing me. Sorry that i haven't got time to experiment further on this topic. I hope @dc42 and his team is looking into it .

                                  1 Reply Last reply Reply Quote 0
                                  • dwuk3dundefined dwuk3d referenced this topic
                                  • dc42undefined
                                    dc42 administrators @dwuk3d
                                    last edited by dc42

                                    @dwuk3d said in Multiple motion system:

                                    On 3.5.4 you can get an axis released by doing T-1 followed by M400 (or probably M598), but on 3.6.0.b4 and rc1 once you have used an AXIS in a motion system it seems to never be released- whatever combination of switching tools, motion systems, M400 and M598's I have tried.

                                    Thanks, I'll try to reproduce this.

                                    EDIT: reproduced, created https://github.com/Duet3D/RepRapFirmware/issues/1099. I intend to fix it before we release 3.6.0-rc.2.

                                    dc42 created this issue in Duet3D/RepRapFirmware

                                    closed Axes not getting released in RRF 3.6.0-rc.1 #1099

                                    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

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

                                      @dwuk3d this is now fixed. Please try the 3.6.0-rc.1+3 binaries from https://www.dropbox.com/scl/fo/geqmn8gbn97n6b587mkbk/AJ2hBIqO-L57_QpR_uqHJ9c?rlkey=fw37wycbp2gil8rvxhe7aopy7&dl=0. Release notes are at https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-RC#reprapfirmware-360-rc2-in-preparation.

                                      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
                                      • dwuk3dundefined
                                        dwuk3d @dc42
                                        last edited by

                                        @dc42 Thanks -thanks that seems to have fixed my issue - I can for example assign T1 to M596 P0, Release T1 with a T-1, and then assign T1 to M596 T1 ok.

                                        Will run further homing sequence and parallel printing tests once I have put machine back together - as am working on some improvements to the rear gantry (P1) at the moment.

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

                                          @dwuk3d thanks for confirming. Please start a new thread if you find any further issues as this thread is already rather long.

                                          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

                                          Alvaundefined 1 Reply Last reply Reply Quote 0
                                          • dc42undefined dc42 marked this topic as a question
                                          • dc42undefined dc42 has marked this topic as solved
                                          • Alvaundefined
                                            Alva @dc42
                                            last edited by

                                            @dc42 Thank you. Confirmed as fixed from my side as well. 🙂

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