What would cause my Z steppers to operate in complete unison when commanded from the LCD but only one moves when the initial command is given to rise to a safe height at the beginning of a g code file? I have measured the variance and it is consistently 5 mm which is the (G1 Z5.08) first g code command sent to the Z steppers. I will post the first part of the g code below.
As an aside, I took apart my ends today and discovered that one side had the skate wheel Y brackets on backward. This is what was causing my binding. I thought the binding was what was causing the left stepper to get out of sync with the right but now that variable has been removed and I am still having the same problem. Also, to try and eliminate the actual motors as the problems I switched them around today. The problem stayed on the left side.
Well, that’s not supposed to be possible. I would guess you’re skipping steps. There is no speed in your initial command there, so who knows what Marlin is using for a desired speed. You could try adding an F300 to the first G0 command. That should move up pretty slowly.
Well, I tried that and while it did not stutter on the start by the time the cutter moved into position approximately 3 feet in the X and 3 feet in the Y the Z on the right was 6mm higher than the left.
I agree… this is very odd.
I am going to program some pauses along the way to see if I can pinpoint the problem.
So let me get some questions answered here. I’m pretty sure you answered some in other thread already, but…
How are your motors wired? Serial? Dual drivers?
Which controller are you using? Ramps or rambo? Rambo mini?
What is the gcode you’re using to do this test? Something simple, I hope?
How are you making sure it’s square when you start? Are you checking the Z height before you power the machine? Your couplers aren’t starting stretched, right?
Does it ever fix itself? Like if you drive back to where you started, is it back to even?
No matter how you have it wired, the software doesn’t drive the two Z motors in a different way, except when homing on dual endstop machines. So the issue isn’t g code or software. You’re either experiencing skipped steps, or maybe a bad driver or wire. Or maybe I’m just not understanding the issue. I’m making a lot of guesses on your testing procedure.
