I’m sure that this was working before, and now… I don’t know what’s wrong.
I’ve been trying to work out things with my LR2, trying to square the endstops. THe process has been going like this: Fire up the LR2, draw a square, then home the Y axis. Adjust the endstops as necessary, rinse and repeat.
Last time I was trying to fine-tune things, (It’s super close, but I think it could be better) when I home either the X or Y axis (Or both) with G28X G28Y or G28XY it lowers the Z axis until it crashes into the table and threatens to stretch the Z couplers. One of the Z couplers wobbles a little when it moves now. It works as expected if I home everything (G28) by homing the Z to the top of travel, then homing X, and last Y. Of course, I don’t WANT to home Z most of the time, since I only really want to do that once in order to level the Z screws. Going to the top of travel takes a long time. Not a big deal if I’m only doing it once, but troublesome for something like this where I’m doing it often.
No idea why it’s trying to LOWER the Z axis as part of the homing operation.
The only thing that I’ve changed since I’m sure that this was working is plugging in the Z probe, but behaviour doesn’t change if I disconnect it.
I wonder if it has anything to do with absolute/relative mode, since Marlin generally raises the Z axis before homing X and Y. I don’t know why homing Z would change that, unless it specifically traps a homed Z because Z is already at maximum.
For the time being, I can deal with it. I need to take apart the sled and put in countersunk screws anyway.
You make me very glad that my end stops are destined to remain in the little baggy they came in for quite some time. BUT keep the cards and letters coming, I understand almost half of what you’ve written above so that’s quite a bit of progress!
It definitely sounds like a safe Z behavior. The same mechanism that raises Z when homing my printer. We could turn that off. Marlin doesn’t have any idea when you turn it on where it is, but I agree with you. I can’t think if a machine where moving down blindly makes any sense. I wonder if it just fell out of the home dir equations.
Well, it’s not like they’re needed but I do like to have the automatic squaring/levelling. Once I get it debugged, it will save time.
That was what I thought. I generally don’t mess with the homing routines in Marlin, because they usually just work the way I expect them to. I’ll have to take a look. I’m currently running the .bin image for the V1CNC_SkrPro_DualLR_2209 repository, with no changes.
I am looking at the zip for V1CNC_SkrPro_DualLR_2209-2.0.7.2-src.zip. It has Z safe homing disabled.
In short, I’m not sure what is causing that. I could dig into the firmware. But since we just jumped to 2.0.9.2, I’d rather do that there. Do you mind trying out v511/2.0.9.2 and see if the issue still exists? If it does, I can try to find time to dig into why it’s doing that, and maybe we can ask the marlin devs what’s going on, or how to fix it.
I don’t have a dual lr firmware on my LR, unfortunately. I never installed endstops on it.
It works as expected if I home everything (G28) by homing the Z to the top of travel, then homing X, and last Y. Of course, I don’t WANT to home Z most of the time, since I only really want to do that once in order to level the Z screws. Going to the top of travel takes a long time. Not a big deal if I’m only doing it once, but troublesome for something like this where I’m doing it often.