X-Y moving before Z finishing it's plunge

[IBBruin]

Just like the title says,

I was recently engraving in ceramic tile using multiple passes removing .0030 each pass to a total depth of .0300. I was Cutting a circle with a cross inside touching at each quadrant. When the cycle was finished, the leading edge (beginning of the XY movement) of the cross was not touching the circle but when the table was at the end of each movement, the line touched the circle. I had to watch the Gcode while I had my hand on the table to even know where to start. It's like when it's executing a z move, about 3 thousandths or so before it get to the bottom of the move, XY starts to move executing the next line of code. It's almost like Z coasts to the full depth of it's plunge in the last .0010 or so.

I hope that made sense.  

Any ideas?

[Hood]

Put it in exact stop mode and see if it still does the same.
Hood

[alenz]

In case Hood’s recommendation doesn’t cure your problem, I would suggest reducing the Z-axis plunge feed rate. Due to machine flex the DRO may show the comanded position before the machine actually gets there.  This lag will result in the ramp that I think you are describing.
Al Lenz

[ger21]

Or, increase the Z acceleration rate, if you can.

[simpson36]

Based on my expericne rounting PC boards, I believe Hood's solution will work.

I wanted to retain CV becuase I use arcs at each change of direction, so my solution was to ad a short G4 delay after each Z down move. You can quickly add this to the existing G-code with any text editor

[stirling]

This is perfectly normal and is down to your Z accel. We're all used to X and Y blending under CV but sometimes forget that Z is also included in a CV blend.

This is why simpson36's fix works because it effectively breaks the Z out of the blend. In fact you don't need an actual delay at all. Anything that separates the Z move from the XY move in the interpreter will do but G4 P0 is as good as anything.