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

    Support Needed for 4-Head Printer Setup: Y Axis Error

    Scheduled Pinned Locked Moved Solved
    General Discussion
    5
    23
    395
    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.
    • Aitorundefined
      Aitor @Aitor
      last edited by

      Good morning,

      I am also sharing this macro, which is where I noticed that the Y (A) axis was not working correctly for tools T2 and T3. In this example, I have commented on the positioning that works correctly, and the part that does not work is when I move the Y axis using the M291 command. However, if I move the X axis, it moves the corresponding axis.

      T0 P0
G28
M98 P"0:/data/PosCal_XY"
var resp = 0

while var.resp != 2
    if var.resp = 0
        G0 X{global.dato0} Y{global.dato1} Z{global.dato2} F6000
        M291 R"Center Tool 0" P"Access to the <a href=""https://emberprototypes.github.io/"" target=""_blank"">camera</a> to position the tool" S3 X1 Y1 Z1
        M400
        set global.dato0 = move.axes[0].userPosition     ;X
        set global.dato1 = move.axes[1].userPosition     ;Y
        set global.dato2 = move.axes[2].userPosition     ;Z
    if var.resp != 2 
        ; homeall
        G91
        G1 H1 F6000 X{-move.axes[0].max -- move.axes[0].min} Y{move.axes[1].max} U{move.axes[3].max} V{-move.axes[4].max -- move.axes[4].min} W{move.axes[5].max} A{-move.axes[3].max}
        G1 H2 F6000 X5 Y-5 U-5 V5 W-5 A5
        G1 H1 F360 X{-move.axes[0].max/2} Y{move.axes[1].max/2} U{move.axes[3].max/2} V{-move.axes[4].max/2} W{move.axes[5].max/2} A{-move.axes[3].max/2}
        G90
        G0 X{global.dato0} Y{global.dato1} Z{global.dato2} F6000
        M400
        M291 R"Verification" P"Make sure that the position is correct before proceeding." S4 K{"Readjust","Recheck","Continue"}
        M400
        set var.resp = input

echo >"0:/data/PosCal_XY" "set global.dato0 = "^{global.dato0}
echo >>"0:/data/PosCal_XY" "set global.dato1 = "^{global.dato1}
echo >>"0:/data/PosCal_XY" "set global.dato2 = "^{global.dato2}

var calX = 0
var calY = 0
var tool = 0

while true
	M291 R"Select Toolhead" P"Indicate the toolhead you want to adjust the offsets for" S4 K{"Exit","Tool_1","Tool_2","Tool_3"}
	set var.tool = input
	if var.tool != 0
		; homeall
		G91
		G1 H1 F6000 X{-move.axes[0].max -- move.axes[0].min} Y{move.axes[1].max} U{move.axes[3].max} V{-move.axes[4].max -- move.axes[4].min} W{move.axes[5].max} A{-move.axes[3].max}
		G1 H2 F6000 X5 Y-5 U-5 V5 W-5 A5
		G1 H1 F360 X{-move.axes[0].max/2} Y{move.axes[1].max/2} U{move.axes[3].max/2} V{-move.axes[4].max/2} W{move.axes[5].max/2} A{-move.axes[3].max/2}
		G90
		T{var.tool} P0
		set var.resp = 0
		while var.resp != 2
			if var.resp = 0
				G0 X{global.dato0} Y{global.dato1} Z{global.dato2} F6000	;In this case, the A axis does position itself correctly.
				M291 R"Center Tool 1" P"Access to the <a href=""https://emberprototypes.github.io/"" target=""_blank"">camera</a> to position the tool" S3 X1 Y1	;When moving the Y axis with tools T2 or T3 selected, the A axis does not move correctly.
				M400
				echo >"temporal" "G10 P"^state.currentTool^" "^move.axes[tools[state.currentTool].axes[0][0]].letter^global.dato0-move.axes[tools[state.currentTool].axes[0][0]].machinePosition
				echo >>"temporal" "G10 P"^state.currentTool^" "^move.axes[tools[state.currentTool].axes[1][0]].letter^global.dato1-move.axes[tools[state.currentTool].axes[1][0]].machinePosition
				M98 P"temporal"
				M400
			if var.resp != 2
				; homeall
				G91
				G1 H1 F6000 X{-move.axes[0].max -- move.axes[0].min} Y{move.axes[1].max} U{move.axes[3].max} V{-move.axes[4].max -- move.axes[4].min} W{move.axes[5].max} A{-move.axes[3].max}
				G1 H2 F6000 X5 Y-5 U-5 V5 W-5 A5
				G1 H1 F360 X{-move.axes[0].max/2} Y{move.axes[1].max/2} U{move.axes[3].max/2} V{-move.axes[4].max/2} W{move.axes[5].max/2} A{-move.axes[3].max/2}
				G90
				G0 X{global.dato0} Y{global.dato1} Z{global.dato2} F6000
				M400
				set var.calX = tools[state.currentTool].offsets[tools[state.currentTool].axes[0][0]]
				set var.calY = tools[state.currentTool].offsets[tools[state.currentTool].axes[1][0]]
				M291 R"Verification" P{"The offset that is set is X="^var.calX^" Y="^var.calY^" so make sure it is correct before proceeding."} S4 K{"Readjust","Recheck","Continue"}
				M400
				set var.resp = input
	else
		break;

M30 "/sys/temporal"
G28
M500 P10:31
M400

      Best regards,

      droftartsundefined 1 Reply Last reply Reply Quote 0
      • droftartsundefined
        droftarts administrators @Aitor
        last edited by

        @Aitor The only odd thing I notice about your config is that the A axis is on a different, CAN connected board. It's possible this is a bug with the M563 axis mapping, though I don't understand why it would work in some cases, and not in others.

        I think the first thing to check is that all boards are on the same firmware. Please send M122, M122 B1 and M122 B2 and post the responses.

        If all boards are on the same firmware, is it possible to swap the A axis onto the main board to test? Ideally keep all XY axes on the mainboard, so move Z (currently on driver 0.5) to the 3HC if possible.

        Ian

        TronXY X5S with Duet 3 MB6HC and Roto toolboard : Cartesian bed-slinger with Duet 3 Mini 5+ WiFi and 1LC : RRP Fisher Delta v1 with Duet 2 Maestro : Polargraph with Duet 2 WiFi

        Aitorundefined 1 Reply Last reply Reply Quote 0
        • Aitorundefined
          Aitor @droftarts
          last edited by

          Good morning @droftarts,

          All the electronics are on the same version, but I am attaching the command responses for you to review.

          console.txt

          The A axis is on a different board due to the arrangement of the axes and the electronics themselves. I have a 6HC and a 3HC at the rear of the machine, and another 3HC at the front, to minimize the amount of cabling. I don't think this should be affecting the setup since, if it were, it wouldn't work at all. However, I can test what you suggested tomorrow and let you know. I usually try to place at least the "XY" axes on the same board for synchronization purposes, but I think I recall reading that this was no longer necessary, which is why I chose this arrangement at the time. Additionally, it saved me from running cables from one end of the machine to the other, as the space I have for cabling is limited.

          If you need more information, please let me know.

          Best regards,

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

            @Aitor said in Support Needed for 4-Head Printer Setup: Y Axis Error:

            That is, when I select my tools T2 or T3 and press, for example, X100 from the panel, it moves the V or W axes (as appropriate) correctly, but when I perform Y100, it does not work properly. This happens when done from a panel, whether it's the web interface, PanelDue, or M291 X1 Y1. However, if you directly send the command G0 X100 Y100, it positions correctly.

            The main difference between using DWC or PD and sending a G1 command directly is the the DWC and PD movement boxes send G91 to put the machine into relative mode, then send the movement command. What happens if you send G91 G0 X100 Y100 G90 starting from X0 Y0?

            Axis A is rotational by default, however the R0 parameter in your M584 command should cause it to be created as linear.

            Are you certain that you haven't configured the A axis maximum speed to be faster than the hardware can handle? Or perhaps you have accidentally set it to to a low motor current?

            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

            Aitorundefined 1 Reply Last reply Reply Quote 0
            • Aitorundefined
              Aitor @dc42
              last edited by

              Good morning @dc42,

              I have reviewed the accelerations, jerk, motor steps, currents, etc., based on the object models, which I find to be the most reliable. If there were any accidental command altering these values, there should be a difference, but in this case, all A[6] values are identical to those of the Y[1] axis.

              Regarding what happens when sending G91 G0 X100 Y100 G90, I found the following surprising:

              After running homeall.g and selecting tool T2, the command worked correctly since the axis starts from X0 Y0 when homed. Even when sending commands repeatedly and trying to "go beyond" the allowed range, everything behaved as expected, without advancing beyond the configured limits.

              However, when doing the same with T3, which starts at X562 and Y0 when homed, I made a mistake by sending G91 G0 X100 Y100 G90. The expected result was for X not to move since that is its maximum limit, and for Y(A) to advance 100 mm. But what actually happened was that neither X nor Y(A) moved; only a small noise, like a loss of steps, could be heard, though not long enough to have moved 100 mm. Despite this, on the DWC panel, the Y and A positions changed to 100.

              In contrast, if I home and then send G91 G0 X-100 Y100 G90, everything moves correctly, even when the command is sent repeatedly until it reaches the configured limits, stopping as it should. Furthermore, once the limits are reached, repeatedly sending G91 G0 X100 Y-100 G90 does not cause it to leave the permitted area. I tried several other combinations; for example, if after homing I send G91 G0 X100 Y-100 G90, there is no movement or noise, as expected. In other words, the error only occurs when sending G91 G0 X100 Y100 G90 with tool T3.

              This behavior is quite strange and has left me puzzled. If you have any other suggestions for tests I could perform, please let me know.

              Best regards,
              Equipo de soporte.

              Aitorundefined 1 Reply Last reply Reply Quote 0
              • Aitorundefined
                Aitor @Aitor
                last edited by

                Good morning @dc42,

                I forgot to mention that the noise I hear is the same as when I try to manually move the Y(A) axis from the web interface, PanelDue, or M291 X1 Y1, regardless of the distance I try to move. And from here, neither T2 nor T3 works.

                Best regards,

                Aitorundefined 1 Reply Last reply Reply Quote 0
                • Aitorundefined
                  Aitor @Aitor
                  last edited by

                  Good morning @dc42,

                  Following our discussion yesterday, today I have carried out the following tests for all the heads, executing the macro I generated.

                  G28
echo >"test" "; Test Start"
var resp = 0
while true
    M291 R"Select Toolhead" P"Specify the toolhead you want to adjust the offsets for" S4 K{"Tool_0","Tool_1","Tool_2","Tool_3","Exit"}
    set var.resp = input
    if var.resp = 4
        break;
    else
        T{var.resp}
        echo >>"test" "T"^state.currentTool^" X="^move.axes[tools[state.currentTool].axes[0][0]].machinePosition^" Y="^move.axes[tools[state.currentTool].axes[1][0]].machinePosition
        G91 G0 X100 Y100 F6000 G90
        M291 R"Did it move correctly?" P"Indicate if the expected behavior occurred for G91 G0 X100 Y100 G90" S4 K{"YES","NO"}
        if input = 0
            echo >>"test" "; G91 G0 X100 Y100 G90 executed correctly"
        else
            echo >>"test" "; G91 G0 X100 Y100 G90 did NOT execute correctly"
        G91
        G1 H1 F6000 X{-move.axes[0].max -- move.axes[0].min} Y{move.axes[1].max} U{move.axes[3].max} V{-move.axes[4].max -- move.axes[4].min} W{move.axes[5].max} A{-move.axes[3].max}
        G1 H2 F6000 X5 Y-5 U-5 V5 W-5 A5
        G1 H1 F360 X{-move.axes[0].max/2} Y{move.axes[1].max/2} U{move.axes[3].max/2} V{-move.axes[4].max/2} W{move.axes[5].max/2} A{-move.axes[3].max/2}
        G0 X-100 Y100 F6000 G90
        M291 R"Did it move correctly?" P"Indicate if the expected behavior occurred for G91 G0 X-100 Y100 G90" S4 K{"YES","NO"}
        if input = 0
            echo >>"test" "; G91 G0 X-100 Y100 G90 executed correctly"
        else
            echo >>"test" "; G91 G0 X-100 Y100 G90 did NOT execute correctly"
        G91
        G1 H1 F6000 X{-move.axes[0].max -- move.axes[0].min} Y{move.axes[1].max} U{move.axes[3].max} V{-move.axes[4].max -- move.axes[4].min} W{move.axes[5].max} A{-move.axes[3].max}
        G1 H2 F6000 X5 Y-5 U-5 V5 W-5 A5
        G1 H1 F360 X{-move.axes[0].max/2} Y{move.axes[1].max/2} U{move.axes[3].max/2} V{-move.axes[4].max/2} W{move.axes[5].max/2} A{-move.axes[3].max/2}
        G0 X-100 Y-100 F6000 G90
        M291 R"Did it move correctly?" P"Indicate if the expected behavior occurred for G91 G0 X-100 Y-100 G90" S4 K{"YES","NO"}
        if input = 0
            echo >>"test" "; G91 G0 X-100 Y-100 G90 executed correctly"
        else
            echo >>"test" "; G91 G0 X-100 Y-100 G90 did NOT execute correctly"
        G91
        G1 H1 F6000 X{-move.axes[0].max -- move.axes[0].min} Y{move.axes[1].max} U{move.axes[3].max} V{-move.axes[4].max -- move.axes[4].min} W{move.axes[5].max} A{-move.axes[3].max}
        G1 H2 F6000 X5 Y-5 U-5 V5 W-5 A5
        G1 H1 F360 X{-move.axes[0].max/2} Y{move.axes[1].max/2} U{move.axes[3].max/2} V{-move.axes[4].max/2} W{move.axes[5].max/2} A{-move.axes[3].max/2}
        G0 X100 Y-100 F6000 G90
        M291 R"Did it move correctly?" P"Indicate if the expected behavior occurred for G91 G0 X100 Y-100 G90" S4 K{"YES","NO"}
        if input = 0
            echo >>"test" "; G91 G0 X100 Y-100 G90 executed correctly"
        else
            echo >>"test" "; G91 G0 X100 Y-100 G90 did NOT execute correctly"
        G91
        G1 H1 F6000 X{-move.axes[0].max -- move.axes[0].min} Y{move.axes[1].max} U{move.axes[3].max} V{-move.axes[4].max -- move.axes[4].min} W{move.axes[5].max} A{-move.axes[3].max}
        G1 H2 F6000 X5 Y-5 U-5 V5 W-5 A5
        G1 H1 F360 X{-move.axes[0].max/2} Y{move.axes[1].max/2} U{move.axes[3].max/2} V{-move.axes[4].max/2} W{move.axes[5].max/2} A{-move.axes[3].max/2}
        G90
G28

                  This was the result of the test I conducted; please note that T# X = starting point position, Y = starting point position.

                  ; Test Start
T0 X=-62.000 Y=375.000
; G91 G0 X100 Y100 G90 executed correctly
; G91 G0 X-100 Y100 G90 executed correctly
; G91 G0 X-100 Y-100 G90 executed correctly
; G91 G0 X100 Y-100 G90 executed correctly
T1 X=562.000 Y=375.000
; G91 G0 X100 Y100 G90 executed correctly
; G91 G0 X-100 Y100 G90 executed correctly
; G91 G0 X-100 Y-100 G90 executed correctly
; G91 G0 X100 Y-100 G90 executed correctly
T2 X=-62.000 Y=0.000
; G91 G0 X100 Y100 G90 executed correctly
; G91 G0 X-100 Y100 G90 did NOT execute correctly
; G91 G0 X-100 Y-100 G90 executed correctly
; G91 G0 X100 Y-100 G90 executed correctly
T3 X=562.000 Y=0.000
; G91 G0 X100 Y100 G90 did NOT execute correctly
; G91 G0 X-100 Y100 G90 executed correctly
; G91 G0 X-100 Y-100 G90 executed correctly
; G91 G0 X100 Y-100 G90 executed correctly

                  In the two combinations where it failed, the previously mentioned noise was heard, but the head practically remains in the same position it was in. In both cases, the expected behavior would have been for the head not to move in X, but to move in Y.

                  Best regards,

                  Aitorundefined 1 Reply Last reply Reply Quote 0
                  • Aitorundefined
                    Aitor @Aitor
                    last edited by

                    Good morning @dc42,

                    After this test, I wanted to simplify it further by only moving the Y-axis. Here is the code used:

                    G28
echo >"test" "; Test Start"
var resp = 0
while true
    M291 R"Select Toolhead" P"Specify the toolhead you want to adjust the offsets for" S4 K{"Tool_0","Tool_1","Tool_2","Tool_3","Exit"}
    set var.resp = input
    if var.resp = 4
        break;
    else
        T{var.resp}
        echo >>"test" "T"^state.currentTool^" X="^move.axes[tools[state.currentTool].axes[0][0]].machinePosition^" Y="^move.axes[tools[state.currentTool].axes[1][0]].machinePosition
        G91 G0 Y100 F6000 G90
        M291 R"Did it move correctly?" P"Indicate if the expected behavior occurred for G91 G0 Y100 G90" S4 K{"YES","NO"}
        if input = 0
            echo >>"test" "; G91 G0 Y100 G90 executed correctly"
        else
            echo >>"test" "; G91 G0 Y100 G90 did NOT execute correctly"
        G91
        G1 H1 F6000 X{-move.axes[0].max -- move.axes[0].min} Y{move.axes[1].max} U{move.axes[3].max} V{-move.axes[4].max -- move.axes[4].min} W{move.axes[5].max} A{-move.axes[3].max}
        G1 H2 F6000 X5 Y-5 U-5 V5 W-5 A5
        G1 H1 F360 X{-move.axes[0].max/2} Y{move.axes[1].max/2} U{move.axes[3].max/2} V{-move.axes[4].max/2} W{move.axes[5].max/2} A{-move.axes[3].max/2}
        G0 Y-100 F6000 G90
        M291 R"Did it move correctly?" P"Indicate if the expected behavior occurred for G91 G0 Y-100 G90" S4 K{"YES","NO"}
        if input = 0
            echo >>"test" "; G91 G0 Y-100 G90 executed correctly"
        else
            echo >>"test" "; G91 G0 Y-100 G90 did NOT execute correctly"
        G91
        G1 H1 F6000 X{-move.axes[0].max -- move.axes[0].min} Y{move.axes[1].max} U{move.axes[3].max} V{-move.axes[4].max -- move.axes[4].min} W{move.axes[5].max} A{-move.axes[3].max}
        G1 H2 F6000 X5 Y-5 U-5 V5 W-5 A5
        G1 H1 F360 X{-move.axes[0].max/2} Y{move.axes[1].max/2} U{move.axes[3].max/2} V{-move.axes[4].max/2} W{move.axes[5].max/2} A{-move.axes[3].max/2}
        G90
G28

                    These are the test results:

                    ; Test Start
T0 X=-62.000 Y=375.000
; G91 G0 Y100 G90 executed correctly
; G91 G0 Y-100 G90 executed correctly
T1 X=562.000 Y=375.000
; G91 G0 Y100 G90 executed correctly
; G91 G0 Y-100 G90 executed correctly
T2 X=-62.000 Y=0.000
; G91 G0 Y100 G90 did NOT execute correctly
; G91 G0 Y-100 G90 executed correctly
T3 X=562.000 Y=0.000
; G91 G0 Y100 G90 did NOT execute correctly
; G91 G0 Y-100 G90 executed correctly

                    The symptoms are the same.

                    If you think of any other tests I could perform, please let me know. On the other hand, if you find it appropriate, I can try installing the version you have released, 3.5.3-rc.1.

                    Kind regards,

                    droftartsundefined 1 Reply Last reply Reply Quote 0
                    • droftartsundefined
                      droftarts administrators @Aitor
                      last edited by

                      @Aitor Have you tried swapping the A axis from the 3HC expansion board to the mainboard? Also, yes, please test with 3.5.3-rc.1.

                      Ian

                      TronXY X5S with Duet 3 MB6HC and Roto toolboard : Cartesian bed-slinger with Duet 3 Mini 5+ WiFi and 1LC : RRP Fisher Delta v1 with Duet 2 Maestro : Polargraph with Duet 2 WiFi

                      Aitorundefined 1 Reply Last reply Reply Quote 0
                      • Aitorundefined
                        Aitor @droftarts
                        last edited by

                        Good morning @droftarts,

                        I’ve tried changing the A axis to the main board, but it’s still not working. With heads T2 and T3 selected, if I send G91 G0 Y100 G90, they should move, but they don’t. The only difference now is that I don’t hear any noise when sending the command; before, I did. However, if I send the code G91 G0 A100 G90, it does work.

                        I’m going to revert to my previous configuration and try installing versions 3.4.5 (which I know worked with another similar setup, although in that case, the A axis was on the main board) and also try version 3.5.3-rc.1.

                        Note: I’d prefer not to use 3.4.5 if it works, as I use many of the new features in 3.5.

                        Best regards,

                        Aitorundefined 1 Reply Last reply Reply Quote 0
                        • Aitorundefined
                          Aitor @Aitor
                          last edited by

                          Good morning @droftarts,

                          I don’t know what to think anymore. Before reverting to the previous configuration, I decided to keep my setup as it was, with the A axis on the main board, to resemble the version I tested earlier. The result was that it still doesn’t work. Here’s another issue: in most of my codes, I always use G90, so it’s possible I didn’t realize this wasn’t working. Now, using the macro I mentioned earlier, which I didn’t have in previous models, I’ve noticed the problem. So, I’m not sure if it’s a firmware issue or a configuration problem. I’ll continue testing and will review my entire configuration again. If you have any other suggestions on what I could try, it would be greatly appreciated.

                          Best regards,

                          Aitorundefined 1 Reply Last reply Reply Quote 0
                          • Aitorundefined
                            Aitor @Aitor
                            last edited by

                            Good morning @droftarts,

                            I’ve tried everything I could think of and reviewed my entire configuration, especially the parts that might be executed when the machine starts up and the files that run before sending G91 G0 Y100 G90, such as tfree#.g, tpost#.g, tpre#.g, homeall.g, config-override.g, and autopower.g (a custom file called from config.g to resume printing after a power loss). However, I don’t see anything that could be causing this error. Additionally, I’ve made sure that in the object models, tools[2].axes[1][0] and tools[3].axes[1][0] are both set to 6 (A), and when I send G90 G0 Y100, these heads respond correctly. Therefore, I’m beginning to suspect it could be a firmware issue that hasn’t been detected until now. @dc42, if you could confirm whether this is possible, I would greatly appreciate it. If you need any additional information, I’d be happy to provide it. Since the machine is for a client, depending on the information you request, I’ll send it to Tony via email.

                            I’ve also tried the newly released version, and the result is the same.

                            Best regards,

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

                              @Aitor I'm pleased to report that @droftarts has now reproduced this issue. We'll fix it in 3.5.3 and in 3.6.0 beta 1 and we'll make a preview available to you early next week so that you can confirm the fix.

                              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
                              • o_lampeundefined
                                o_lampe
                                last edited by o_lampe

                                @Aitor I followed the thread with great interest, because I had no config/toolchange problem with my #hash printer which has 4 independent heads with cartesian kinematics.
                                I used to use RRF3.2 or 3.3, it might be worth to roll back to these FW versions and verify.
                                I also used Duet2 and an expansion board, so no possible CAN-address -issues either.

                                Aitorundefined droftartsundefined 2 Replies Last reply Reply Quote 0
                                • Aitorundefined
                                  Aitor @o_lampe
                                  last edited by

                                  Good morning @dc42 and @droftarts,

                                  Thank you very much for the help provided. I will keep an eye on the mentioned versions, run the tests, and report back with the results.

                                  @o_lampe, this error does not exist in version 3.3; @droftarts confirmed this for me. Additionally, upon reviewing my notes from a similar model, I found that this issue was indeed present in that version, which is why I didn’t encounter the problem before. However, in that model, I used Duet2 Wifi, so I wasn’t sure if this was the cause.

                                  Thanks again to everyone for the support.

                                  Best regards,

                                  droftartsundefined 1 Reply Last reply Reply Quote 0
                                  • droftartsundefined
                                    droftarts administrators @o_lampe
                                    last edited by droftarts

                                    @o_lampe I initially tested 3.3, 3.4.6, 3.5.2 and 3.6.0-alpha.5. 3.3 works correctly, while 3.4.6, 3.5.2, 3.6.0-alpha.5 all exhibit the bug, ie individual Y axis move causes mapped axis not to move.

                                    Last night I narrowed it down to changes made in 3.4.2, as 3.4.1 works correctly, but 3.4.2 does not. I can't see anything obvious in the 3.4.2 release notes that would have caused the change in behaviour, though: https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x#reprapfirmware-342

                                    Edit: and now, even more specifically, 3.4.2rc2 works correctly, 3.4.2rc3+ does not. For firmware debugging fans, @dc42 suspects this commit, https://github.com/Duet3D/RepRapFirmware/commit/63198ff741ddb2c2c86a49284d5e653fab234dd2, in particular the lines that update and use linearAxesMentioned and rotationalAxesMentioned

                                    Edit: Issue raised on Github: https://github.com/Duet3D/RepRapFirmware/issues/1043

                                    Ian

                                    droftarts created this issue in Duet3D/RepRapFirmware

                                    closed [Bug]: Y-axis only moves fail when another axis is mapped to Y with M563 #1043

                                    0 dc42 committed to Duet3D/RepRapFirmware 
                                    Attempted fix for extruder-only moves after M400 with tapered bed comp

                                    TronXY X5S with Duet 3 MB6HC and Roto toolboard : Cartesian bed-slinger with Duet 3 Mini 5+ WiFi and 1LC : RRP Fisher Delta v1 with Duet 2 Maestro : Polargraph with Duet 2 WiFi

                                    1 Reply Last reply Reply Quote 1
                                    • droftartsundefined
                                      droftarts administrators @Aitor
                                      last edited by

                                      @Aitor Thanks to @AndyE3D, we've found a workaround for this issue. The A axis, though it has been set as a linear axis with the M584 R parameter, is still regarded as a rotational axis in feedrate calculations, and so was being ignored when mapped to an axis with linear feedrate calculations (I think). The workaround is to implicitly set it as an axis with linear feedrate calculations, with the M584 S0, eg:

                                      M584 X0.1 Y0.0 Z1.0 U0.2 V0.3 W0.4 A0.5 R0 S0

                                      This seems to get around the issue, and when mapped to the Y axis, the A axis moves correctly, at least for me in testing. It's being fixed in the next release so the S parameter defaults to the R parameter if it is set.

                                      Ian

                                      TronXY X5S with Duet 3 MB6HC and Roto toolboard : Cartesian bed-slinger with Duet 3 Mini 5+ WiFi and 1LC : RRP Fisher Delta v1 with Duet 2 Maestro : Polargraph with Duet 2 WiFi

                                      Aitorundefined 1 Reply Last reply Reply Quote 1
                                      • Aitorundefined
                                        Aitor @droftarts
                                        last edited by

                                        Good morning @droftarts,

                                        I’ve implemented the solution you suggested, and in the initial tests, it seems to be working correctly. If I notice anything unusual, I’ll let you know.

                                        I have a question: when this is fixed in the firmware, should I keep S0 or remove it? Or, on the contrary, does it not matter if I leave it in place?

                                        Best regards,

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

                                          @Aitor you can leave it in place, it won't do any harm.

                                          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 1
                                          • dc42undefined dc42 has marked this topic as solved
                                          • First post
                                            Last post
                                          Unless otherwise noted, all forum content is licensed under CC-BY-SA