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

droftarts

@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

Aitor

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,

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?

Aitor

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.

Aitor

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,

Aitor

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,

Aitor

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,

droftarts

@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

Aitor

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,

Aitor

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,

Aitor

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,

dc42

@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.

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.

Aitor

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,

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

droftarts

@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

Aitor

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,

dc42

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