Dual Z homing weird behavior on U limit first
-
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.
-
@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.
-
@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.
-
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 E3homez.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.
