With this z-axis “dive” or skipping problem being discussed in a couple of different threads, I’d add my observations here after spending the better part of the weekend getting to a predictable behavior…
What I had collected from the threads was:
- Feed rate isn’t controlled specifically for Z-axis movement.
- G00 would pick up the previously used feed rate whether it was specified for Z-axis or any other axis.
- Estlcam allows using G01 instead of G00 for rapid movements.
After reading the threads about G00 vs G01, I optimistically set out to get this behind me. Issued a few rapid moves and regular moves, specifying various feed rates and it failed as much with G01 as with G00! Diving into the source of Marlin, it turns out that G00 is automatically interpreted as a G01. So no reason to worry about whether it’s a rapid move or not. This means that (3) is a moot point as my experiments also showed. Marlin is oblivious to the rapid move command. This is the responsible code snippet from Marlin for those who speak code (if a G0 is given it is interpreted exactly as a G1 would be):
if(code_seen(‘G’))
{
switch((int)code_value())
{
case 0: // G0 -> G1
case 1: // G1
if(Stopped == false) {
I did conclude that every now and then the skipping would happen more frequently at higher feed rates, so controlling feed rate seemed like a plausible fix, though I also had skips at lower feed rates. So there had to be more…
I then put power on the stepper using the manual controls in Repetier, then grabbed the Z-axis adjustment nut and turned it. Boom! I pushed over the stepper way easier than I expected, indicating that the hold of the stepper wasn’t as strong as I anticipated. I’ve use the strong motors recommended, but was running the Z-axis on the cooler side (tuned the controller to 600mV => 1.2A). My motors spec’d at 2A for max hold, so I turned up the holding current by adjusting the controller to 800mV. Much better. More testing showed that I still had the skips, but way less. Then upped the controller to 900mV (1.8A for the stepper) and now I could hardly turn over the stepper. The test has now completed a 1h run with 10 layers, returning to the exact starting point, so no skips! The stepper does get hotter now (~90F after the hour long job) but well within the 80C temperature raise the stepper is rated for in an ambient temp range of 20-50C.
So in the end for me this was not simply about overdriving the axis with feed rate out of control. It will take F2400 just fine now. It was about the lack of torque of the Z-axis motor as a result of running it too cool. Could say that’s the same thing - but the cure was to drive the stepper hotter as I couldn’t go low enough (within reason) on the feed rate.
In the process I also found an option in Estlcam that allows issuing federate for all the move commands (checking on the “repeat” option for the “F” setting). While this gives explicit feed rate on every command and thus should eliminate (or at least limit) risk of inheriting “wrong” feed rate, I am not sure that it’s really helping now considering the other changes I’ve done.
Hope this helps others in their chase.
PS: In the process, I also concluded that the lack of specifying feed rate is the cause of the occasional glacially slow move to the first point of a job. Including a “G01 F1600” in the header of the job ensures that feed rate starts out right before being specified the first time. This might be what Christian hints at above with the “add a ‘F’ word for initialisation” - it just took me a while to internalize that 
