Dual Z homing weird behavior on U limit first



  • I've been tearing my hair out on this one for a little while because everything almost works. I'm using a Duet Maestro on 2.02

    I'm using this method for doing dual axis Z homing with independent steppers: https://duet3d.dozuki.com/Wiki/Bed_levelling_using_multiple_independent_Z_motors

    When I trigger my home routine, both axes move down. If the Z axis hits the limit first, the U axis continues to it's limit while the Z axis stops.

    If the U axis hits first, both axes continue until the Z axis hits it's limit. This, of course, prevents the auto leveling feature from working if the U axis is ever below the Z axis.

    I think I can modify my homing procedure to account for this but it's unexpected behavior.

    Am I doing something obviously wrong here?

    Thanks!

    0_1545853928780_homez.g


  • administrators

    I think the problem is that during homing, you have driver 4 configured as both Z and U. You have command M584 Z2 in your homez.g file to disconnect driver 4 from Z, but it is commented out.

    Also, if you have hidden the U axis using the P parameter of the M584 command, you need to make it visible during homing.

    See this guide https://duet3d.dozuki.com/Guide/Independent+Z+motors+and+endstop+switches/18?lang=en.



  • I totally did not find that link when I was looking. That seems to have solved the problem. Thank you!



  • I made the suggested fixes yesterday and things seemed to work. Today, the U axis won't move. Which makes me exceptionally sorry and embarrassed to come back here looking for help again!

    If I try to walk through HomeZ line by line, everything goes fine until I get to line 28:

    ; Rapid Z+U until limit switch triggers
    G0 Z450 U450 F1500 S1

    Edit: See below for some testing results

    I am on firmware 2.02 and did do a re-upload of the firmware. I'm stuck again and out of ideas.

    0_1546033672150_config.g
    0_1546033676285_homez.g



  • It should be noted that the other Z axis (the one that is Z) will work fine whatever I do with it.



  • I loaded my old home file in and, while both axes will move for home, the U does not continue down to the limit switch after Z is triggered.

    I did swap out my XY motors yesterday and this problem seems to have occurred after that but The U axis works just fine when joined to Z so I didn't screw up the wiring and I'm presuming I did not blow up the board.

    I'm at a loss and don't even know what information to provide!



  • Further testing:

    There seems to be something wrong with the S1 parameter for the U axis.

    • Restart my system with Z and U split
    • M564 H0 S0
    • G91 to go into relative mode
    • G0 U10 Z10 F500 -everything moves
    • I can repeat these relative moves repeatedly.

    Things fall apart when I do an S1 Move

    • G92 Z0 U0 for good measure

    • G0 U1 Z1 S1 - Both axes move 1mm toward my limit

    • Z position now shows 1mm, U shows my axis maxima 370

    • U will no longer move down to the limit since it appears to not be ignoring the limits!

    • Reset the machine for good measure

    • M564 H0 S0

    • G91

    • Do some relative moves for good measure

    • G0 U400 Z400 S1 - Both axes move toward the limit. U stops after about 30mm, Z continues moving.

    • At this point I estop the machine since it can't finish homing but I presume this is due to the same limit issue above.

    With this bug, it's hard to confirm whether the gantry style dual limit switch is even working but I'm not confident it is based on what I've seen from trying to home close to the limits.



  • @LeonMF here is what I do to home my Z -- it's 4 lead screws but would apply to you as well. Make sure you do M584 before you start motion -- also S1 is homing, S2 used to back away in the opposite direction -- it can be used when the printer is not homed.

    M584 Z6 B7 C8 D9 P10
    G91
    G1 Z6 B6 C6 D6 F450 S2
    G1 Z-500 B-500 C-500 D-500 F450 S1
    G1 Z5 B5 C5 D5 F450 S2
    G1 Z-10 B-10 C-10 D-10 F100 S1
    M584 Z6:7:8:9 P7
    M671 X708:708:-95:-95 Y615:0:0:615 S5
    G92 Z0 B0 C0 D0
    G90



  • @kazolar I am doing a proper M584 in my homing file and I don't understand how S2 would help. My problem is that the U axis stops moving when it appears reaches some internal movement limit.



  • Here is my workaround homing file.

    • I added lines 23-28 prehoming the z axis to the limit switch. This allows the U axis to get close enough for gantry homing to work.
    • the next key element is line 41 where I reset the current position of U to be within the machine limits.
    • If also disabled lines 38 and 44 because they are taken care of by the previous two bullet points.

    It's not perfect but it gets me back on track.

    0_1546191549112_homez.g



  • @LeonMF S2 allows moves which disregard end stop trigger or soft limits, with S2 moves you are allowed to move where ever and under whatever conditions you want -- some prohibitions have been introduced and have been hardened since, so the only way to bypass them is to use S2 for none S2 moves



  • @kazolar Right, but the problem is that the travel to the home switch using S1 is what's broken. I'm not having trouble (now) traveling X and U without the S1 parameter as long as I reset the U axis to be within machine bounds.



  • @LeonMF I think doing an initial back off with S2 accomplishes just that, it basically allows for S1 move to proceed properly.



  • @kazolar I tried using the S2 flag and it doesn't help the stalled U moves. It does help the first move after homing to be normal speed rather than super slow.



  • @dc42 I know today is New Year's and it's after normal business hours so I don't expect an immediate response. When you are back to looking into forum thing again, I'd appreciate any input you can give.

    For some reason, the latest work around file stopped working for me after a couple of tries similar to the way the non-workaround script stopped working after initially working. I have no idea what to test, what to look for and I'm at a loss for what to do!

    I'm happy to run any tests you suggest.


  • administrators

    @leonmf said in Dual Z homing weird behavior on U limit first:

    Further testing:
    There seems to be something wrong with the S1 parameter for the U axis.

    Restart my system with Z and U split
    M564 H0 S0
    G91 to go into relative mode
    G0 U10 Z10 F500 -everything moves
    I can repeat these relative moves repeatedly.

    Things fall apart when I do an S1 Move

    G92 Z0 U0 for good measure

    G0 U1 Z1 S1 - Both axes move 1mm toward my limit

    Z position now shows 1mm, U shows my axis maxima 370

    What I think is happening is that the firmware thinks the U endstop switch has been triggered. Likely causes are:

    • A bad crimp connection on the U axis endstop connector. Your U endstop is active high, so a disconnected endstop will look like a trigerend endstop.
    • Your M574 endstop parameters have become corrupted.

    I suggest you send M584 P4 to enable the U axis, then send M119 to check what the Z and U endstop switches are reporting. Also send M574 without parameters to check that the Z and U endstop switch settings are correct.



  • @dc42 Checking the end stops is one of the first things I did but I didn't look deeply into it. A spotty end stop could definitely explain the problem.

    I'll report back here when I've confirmed. Thank you!



  • I've confirmed a loose connector that was still tight enough to work sometimes. Thank you.


  • administrators

    Thanks, I'll mark this as solved.



  • I ever face to your problem when I try to use dual Z independence. I found the solution as below;

    Config.g
    ;Define Axis
    M584 X0 Y1 Z2:4 U4 V2 E3

    homez.g
    G91 ; relative positioning
    G1 V5 U5 F6000 S2 ; lift Z relative to current position
    G1 S1 V-405 U-405 F1800 ; move Z down until the endstop is triggered
    G92 V0 U0 Z0 ; set Z position to axis minimum (you may want to adjust this)

    We need setup one more axis and home the individual driver. So it will true independence endstop one each driver.


 

Looks like your connection to Duet3D was lost, please wait while we try to reconnect.