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

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.