[CLOSED] Help! Going nuts with Marlin and my special 3 Z screws.

I doubt he is doing any special math after the initial bed leveling is done. The 3 Z motors should get exactly the same signal after bed leveling is complete. It is a cartesian style printer of some sort, after all. It is not like it is a delta printer.

@NathanielStenzel yes, my will to make it simple is why I “sniff” the step/dir pulses directly from the (empty) Z pololu socket into my slave, which simply re-dispatch it to its 3 Z. And I’ll switch to logic gates soon or later indeed (the sooner the better may be…).

Back to A/B/C cases, here is the full test.
(the slash in my gcode was only to make it more compact, obviously I’m sending individual lines instead)

; Common initialization
G100 ; full bed calibration (home made)
G0 X100 Y100 ; move to ~center

;------------- A move 10 x and 10 z
G0 X10 Z10
G0 Z0 ; ends up ~1.5mm too high

;------------- B move 10x 10y 10z
G0 X10 Y10 Z10
G0 Z0 ; ends up ~1.5mm too high (idem)

;------------- C move 10y 10z
G0 Y10 Z10
G0 Z0 ; ends up ~1.5mm too high (idem)

Bed is still perfectly level. Only Z0 reference is wrong. Homing or calibration makes it fine again.

For completeness, variations to your case A (still with the same newly calibrated bed):

;------------- A2 (higher Z move)
G0 X10 Z80
G0 Z0 ; slightly bigger Z gap (~2mm)

;------------- A3 (shorter Z move)
G0 X50 Z10
G0 Z0 ; ~0.75 mm abusive gap (half of A)

;------------- A4 (inverse Z move)
G0 Z10
G0 X10 Z0 ; crashes the head reciprocally

So: the Z drift seems bigger with longer moves, unless the move is perfectly vertical. It does not depend on the number of moving steppers. :s

Ok, I didn’t realize the bed was still level, but just at the wrong z height (I thought you said only 1 of the 3 was off). If you’re confident the steppers are not missing steps, then could it be a rounding error? I realize that is a big error for rounding, but perhaps it is a small error getting magnified?

@Jeremie_Francois okay. I guess it is not a power issue then, but something does not seem right with your software. I guess switching to smoothie board or similiar might work better. I just have to wonder if you have something that can handle 5 stepper motors for movement and 1 or 2 for extruders. That is 6 or 7 steppers, a heated bed and a hot end or two. That is alot of things to control. Good luck.

Yep I am really fed up with marlin :confused:
Time to switch. Hope I’m not bashing it instead of me, but seriously I really do not know how this can happen. May be I am saturating a tight loop, e.g. fast step interrupts or so. As for the steppers, the 3 of them do act as a whole (like some printers have 2 Z). When they act individually, only one stepper is active a give time, since it is during calibration. So the excess number of steppers is not an issue here imho.

@Jeremie_Francois Wait a minute…I forgot you had a separate grbl shield for the Z axis steppers over custom serial. Is it possible the communication over that port is the problem, like first or last serial commands getting dropped?

Actually no b/c once calibration is done (just a command via serial indeed), then the slave is switched to fast and transparent mode: the usual step/dir signal changes from marlin on the ramps trigger a hardware interrupt on the slave who then just propagate their state to its 3 own Z (5 lines of code may be). I.e. no more serial use. Also no software overhead on the master. And I double checked that I lose no steps through the grbl shield slave when I test it, using really high z speed (and the issue happens anyway also with very slow z pulses). Really looks like a math issue in marlin, but I really have no clue why it would happen here, and in such a weird manner. I should better use hardware multiplexing indeed, less software, and then forget also about marlin if the issue is still happenning. Quite depressing :confused:

Thanks guys. Many of you were spot on: electronic noise. I was able to trace it this morning with a logic analyser. The stepper 8us short pulses were sometimes not received, and I saw spurious and often extremely short pulses on the “dir” signal! Thanks again for your help :smiley:
Ref: https://plus.google.com/u/0/+JeremieFrancois/posts/FiduVeKYuqH