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

    Core XYU Z Movement Issue

    Scheduled Pinned Locked Moved
    General Discussion
    5
    33
    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.
    • pcsentinelundefined
      pcsentinel @hackinistrator
      last edited by

      @hackinistrator Sorry, but I think you are wrong, please see: the link from above. Also the firmware code from the Duet is as follows:

      case KinematicsType::coreXYU:
      	// Core XYU is like CoreXY with an additional U axis controlled by the U and V motors
      	inverseMatrix(0, 1) = 1.0;
      	inverseMatrix(1, 0) = 1.0;
      	inverseMatrix(1, 1) = -1.0;
      	inverseMatrix(1, 3) = 1.0;
      	inverseMatrix(1, 4) = -1.0;
      	inverseMatrix(3, 4) = 1.0;
      	inverseMatrix(4, 4) = 0.0;		// V can't be commanded directly
      	break;
      
      case KinematicsType::coreXYUV:
      	// CoreXYUV is a dual CoreXY setup
      	inverseMatrix(0, 1) = 1.0;
      	inverseMatrix(1, 0) = 1.0;
      	inverseMatrix(1, 1) = -1.0;
      	inverseMatrix(3, 4) = 1.0;
      	inverseMatrix(4, 3) = 1.0;
      	inverseMatrix(4, 4) = -1.0;
      	break;
      

      i.e. a core XYUV effectively has two XY carriages whereas a Core XYU has 2 heads mounted on a single Y carriage.

      I am guessing I have 1 setting wrong somewhere that is causing this issue. Do you have a Core XYU machine, if so maybe you could post the config.g so that I can do a comparison.

      Rushmere3Dundefined hackinistratorundefined 2 Replies Last reply Reply Quote 0
      • Rushmere3Dundefined
        Rushmere3D @pcsentinel
        last edited by

        @pcsentinel

        Can you post some pictures of your machine?

        Follow my adventures in 3D Printing, laser cutting and electronics. https://linktr.ee/Rushmere3D

        pcsentinelundefined 1 Reply Last reply Reply Quote 0
        • hackinistratorundefined
          hackinistrator @pcsentinel
          last edited by

          @pcsentinel please tell hoy many motors connected to your second carriage .
          its possible to make coreXYUV with single gantry , if 2 motors control second carriage .

          pcsentinelundefined 1 Reply Last reply Reply Quote 0
          • pcsentinelundefined
            pcsentinel @hackinistrator
            last edited by

            @hackinistrator There are4 motors controlling the XYU carriage. please see my post above which shows you that the firmware defines that as being core XYU

            1 Reply Last reply Reply Quote 0
            • hackinistratorundefined
              hackinistrator
              last edited by

              then its core XYUV , your m669 is wrong .

              pcsentinelundefined 1 Reply Last reply Reply Quote 0
              • pcsentinelundefined
                pcsentinel @hackinistrator
                last edited by

                @hackinistrator 4 motors:

                case KinematicsType::coreXYU:
                // Core XYU is like CoreXY with an additional U axis controlled by the U and V motors
                inverseMatrix(0, 1) = 1.0;
                inverseMatrix(1, 0) = 1.0;
                inverseMatrix(1, 1) = -1.0;
                inverseMatrix(1, 3) = 1.0;
                inverseMatrix(1, 4) = -1.0;
                inverseMatrix(3, 4) = 1.0;
                inverseMatrix(4, 4) = 0.0; // V can't be commanded directly
                break;

                1 Reply Last reply Reply Quote 0
                • pcsentinelundefined
                  pcsentinel @Rushmere3D
                  last edited by pcsentinel

                  @Rushmere3D Hi, please see the video linked above and below.

                  1 Reply Last reply Reply Quote 0
                  • hackinistratorundefined
                    hackinistrator
                    last edited by hackinistrator

                    you defined custom matrix , not just K5 or K8 . your m669 is wrong .
                    if you have 4 motors for XYUV
                    matrix should be something like that :

                    M669 X1:1:0:0:0   Y1:-1:0:1:-1 Z0:0:1:0:0 U0:0:0:1:1 V1:-1:0:1:-1
                    
                    1 Reply Last reply Reply Quote 0
                    • pcsentinelundefined
                      pcsentinel
                      last edited by

                      I will look at the matrix, but I am failing to understand the relationship to the actual issue, which is that when Tool 0 is active then everything works fine, but when Tool 1 is active then the U is parked for any Y or Z moves.

                      To prove it, here is a video taken with Tool 0 active.x1.mp4

                      1 Reply Last reply Reply Quote 0
                      • pcsentinelundefined
                        pcsentinel
                        last edited by pcsentinel

                        Well, I am now even more confused, I have tried various options including changing the matrix to
                        M669 X1:1:0:0:0 Y1: -1:0:1:-1 Z0:0:1:0:0 U0:0:0:1:1 V0:0:0:0:1

                        moving M584 to above M669

                        But I have now discovered that the issue is intermittent, so when Tool 0 is active then everything always works fine, but when Tool 1 is active, sometimes a G1 Z5 will move the U carriage to its home position (without being told to) whilst at the same time Z moves as instructed, other times just the Z carriage moves as expected.

                        And its not after a config change. Sometimes its as if some internal variable is set or cleared. So everything works, and then you give an instruction and following that the aberration occurs again.

                        The other thing I have noticed is in the pics, If X is homed to -94 (pic1) and then I make Tool 1 active the X location is shown as the U location in the interface.pic1.PNG pic2.PNG

                        hackinistratorundefined 1 Reply Last reply Reply Quote 0
                        • hackinistratorundefined
                          hackinistrator @pcsentinel
                          last edited by

                          @pcsentinel said in Core XYU Z Movement Issue:

                          V0:0:0:0:1

                          why ?
                          V should be same as Y .

                          pcsentinelundefined 1 Reply Last reply Reply Quote 0
                          • pcsentinelundefined
                            pcsentinel @hackinistrator
                            last edited by

                            @hackinistrator Same result, no change.

                            hackinistratorundefined 1 Reply Last reply Reply Quote 0
                            • hackinistratorundefined
                              hackinistrator @pcsentinel
                              last edited by

                              @pcsentinel can you send m669 in console and paste the resuly here?

                              pcsentinelundefined 1 Reply Last reply Reply Quote 0
                              • pcsentinelundefined
                                pcsentinel @hackinistrator
                                last edited by

                                @hackinistrator
                                Kinematics is modified Cartesian, matrix:
                                1.00 1.00 0 0 0
                                1.00 -1.00 0 1.00 -1.00
                                0 0 1.00 0 0
                                0 0 0 1.00 1.00

                                1 Reply Last reply Reply Quote 0
                                • pcsentinelundefined
                                  pcsentinel
                                  last edited by

                                  Further observations.

                                  Following a reboot, with tool 0 active all movement is as expected.
                                  Issue a T1, to make Tool 1 active, issue a G1 Z5, Z moves down and U stays where it is.
                                  Issue a T0 all movement as expected.
                                  Issue a T1 (for the second time) the issue occurs whereby at the same time as the Z movement is taking place, U returns to the home position.

                                  Further, When Tool1 is active G1 U commands acts as expected, but G1 X commands move the U carriage and not the X carriage.

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

                                    I don't suppose you'd be willing to update to RRF3?

                                    Z-Bot CoreXY Build | Thingiverse Profile

                                    pcsentinelundefined 1 Reply Last reply Reply Quote 0
                                    • pcsentinelundefined
                                      pcsentinel @Phaedrux
                                      last edited by

                                      @Phaedrux Hi, I didn't want to, but I am now thinking it may be inevitable, if only to eliminate V2 as a source of the issue.

                                      Just dreading having to go through the conversion process!

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

                                        It's not so bad really. Starting with a clean config might not be the worst thing to do in cases like this.

                                        M201 X1000 Y1000 U1000 V1000 Z250 E250,250

                                        I just noticed in your config a small error. You have a , that should be a :. Things like that can sneak in when you're doing a lot of manual edits.

                                        If you still have access to DWC. Upload these 3 zip files, one at a time in the system tab. Don't extract them. Reboot after each. Use M115 to verify the firmware has been applied.
                                        https://github.com/Duet3D/RepRapFirmware/releases/download/2.05.1/Duet2Firmware-2.05.1.zip
                                        https://github.com/Duet3D/RepRapFirmware/releases/download/3.0/Duet2and3Firmware-3.0.zip
                                        https://github.com/Duet3D/RepRapFirmware/releases/download/3.2.2/Duet2and3Firmware-3.2.2.zip
                                        That will get your firmware and DWC up to date.

                                        You can see the change logs here:
                                        https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x

                                        For your config, might be a good idea to run through the configurator tool and generate a fresh set for RRF3.
                                        https://configtool.reprapfirmware.org/Start

                                        Then you can add back in your additional axis and things.

                                        Backup your existing config files in the sys folder in case you want to switch back to RRF3. IT’s easy to switch back and forth, just upload the zip file for the version you want and then upload your config files.

                                        These documents will come in handy during the conversion.
                                        https://duet3d.dozuki.com/Wiki/RepRapFirmware_3_overview
                                        https://duet3d.dozuki.com/Wiki/Gcode

                                        And testing your config for errors with M98 P"config.g" is helpful.

                                        Z-Bot CoreXY Build | Thingiverse Profile

                                        pcsentinelundefined 1 Reply Last reply Reply Quote 0
                                        • hackinistratorundefined
                                          hackinistrator @pcsentinel
                                          last edited by

                                          @pcsentinel said in

                                          Further, When Tool1 is active G1 U commands acts as expected, but G1 X commands move the U carriage and not the X carriage.

                                          i think this is normal , when T1 selected x movement is tied to u .

                                          what strange is u moves when you try to move z .
                                          maybe remove m501 and try .

                                          1 Reply Last reply Reply Quote 0
                                          • pcsentinelundefined
                                            pcsentinel @Phaedrux
                                            last edited by

                                            @Phaedrux Hi Phaedrux, well I but the bullet and upgraded, it wasn't as bad as I had anticipated. Thanks for the kick up the butt!

                                            I used K5 rather than a full matrix layout as that should be fixed in 3.2.2

                                            Unfortunately it didn't stop the issue from occurring. However as I had spent so long looking at the config, something popped out, The Tool 1 definition includes the X3 command so that X moves are translated to U moves when a normal gcode file is processed. And this points to my other observation above that X moves with Tool1 selected move U and not X. So I thought I would experiment, if you remove the X3 from the line then the issue does not occur, i.e. with tool 1 active Z and Y moves operate exactly as expected.

                                            But of course you cant leave it like that otherwise printing wouldn't work. So I thought well, lets just run a test print with Tool 1 as the active extruder. Guess what Z moves when printing do not cause the U carriage to move home.

                                            So it appears that this issue is only present when not printing and probably (?) only occurs with a CoreXYU configuration. It just makes things hard to tune. And also made me waste peoples time with this non-ish issue.

                                            Note, I have yet to do a full 2 extruder print, but I have more confidence that it will work now.

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