Random Z-Plunge Issue

CNC Machines Shapeoko
1

Hello. I’ve been using my Shapeoko 3 XXL for a while now, and am just coming across this issue. While the machine is running, as it’s going to do the next stepdown, it plunges way too far. There doesn’t seem to be any consistency with how long the machine is running before this error, however, it only seems to occur once every time I turn on/power cycle the machine. After this errant plunge occurs, if I simply restart the g-code, it works just fine. I’ve machined for several hours, running several different programs after the random plunge both times it occurred and there were no further problems.

This happened both times during a facing operation generated by Fusion 360 with the “Carbide 3D (Grbl) / carbide3d” post-processor with the default settings. After the plunge, I felt the temperature of the spindle and all of the stepper motors, all of which were cool to the touch. I’ve seen other posts suggesting that errant z-plunges might be caused by an overheating stepper driver/control board, but given that the machine flawlessly ran the same g-code to completion immediately after the error I don’t believe that to be the case. Does anyone know what could be causing the problem? Thanks in advance!

Image of the result of the plunge below:

IMG_20210423_220308
IMG_20210423_2203082304×1728 1.08 MB

2

I guess you already ruled out the usual suspects,

  • it’s not the Gcode or the same file would not run correctly after the event
  • it’s not Z clearance at the top for the same reason
  • it’s not a problem in setting Z Zero or this would not happen in the middle of a cut (does it happen only on “edges” of the part, or anywhere, even right in the middle?)
  • it’s not the endmill slipping/being pulled out of the collet (or you would have noticed, given how deep it plunged during the event. Did you re-zero afterwards or just reran the same file?)

If you are able to reproduce this issue, it may be worth running with the Log window open (but filtering out status messages), so as to be able to check if there is anything suspicious reported by GRBL when this happens? I’m always prone to imagine complex issues like EMI flipping a bit in the serial communications right when CM is sending a Z move command, but it’s never the case (and if your USB cable was susceptible to EMI, the probability would rather be to loose connection, or that it would happen completely randomly, not just during a Z plunge)

Which Z-axis type do you have?
When this happens does it always plunge by the same extra depth?

3

Thanks for the response.

Regarding the location of the error, yes it only has happened so far at the edge of the part during a facing operation.

Regarding my z-axis, I have the belt-driven version that shipped on the older Shapeokos. I’m not sure if it plunges the same extra depth every time and I don’t previous part to measure, but this time it plunged about 0.338in/8.6mm - I’ll be sure to measure again if the same error repeats itself.

Regarding the re-zeroing, after hitting the stop button, the machine went and re-homed itself, but I didn’t change the zero location, just re-run the same g-code the past two times this occured.

This time however, the stock was way taller than the part, and the facing had been running for quite some time before the z-plunge error happened. I didn’t want to wait around for a long time while the machine was just running through the air, so I found out how much it had cut by touching off the top of the part and noting the z-depth, then I adjusted the stock size accordingly in Fusion 360. Running the new g-code caused the same z plunge to happen again with 11 minutes remaining on the cut. This time, I was running with the log open, so have attached its contents along with the g-code that was running here: Carbide Motion Log and GCODE · GitHub

Immediately after I paused the machine, I took off the electronics cover box and touched all of the ICs, which were all slightly warm, but not too hot. All of the stepper motors and the spindle were cool to the touch, as they were before.

I’ll run the same g-code again with no changes or re-zeroing to see what happens probably sometime tomorrow.

Just in case it’s useful, the GRBL version is 1.1f, and the carbide motion is build 513.

Should I try updating carbide motion?

Based on the new info, any more thoughts? Thanks again!

Image of most recent errant z-plunge:

IMG_20210424_142933
IMG_20210424_1429332304×1728 1.69 MB

1 Like
4

Why does this look familiar. Typical Z belt lost steps problem. The way I handled it was to make sure that I lowered my Z, off the material… Always! A little bit of a pain but it’s a sacrifice you pay for that style Z.

5

The guy who machines metal 90+ percent of the time, I really really really recommend the Z plus Head.

1 Like
6

Thanks for the input. The z-axis is lowering outside of the material. I might be missing something, but in this instance, it doesn’t seem to make sense that it is lost steps, as this occurs after it finishes one pass, then retracts, moves to the front of the stock, plunges outside of the material, and moves into the material laterally. When the errant z-plunge occurs, it goes way to far down before it even touches the metal, but should have no resistance while retracting, and seems to be at the correct z-height while traveling.

Here’s an image of the plunge location and the preceding travel path:

Plunge Location
Plunge Location1324×930 38.8 KB

7

Also, while I would love the z-plus upgrade, unfortunately, it isn’t something I can get right now. The belt drive certainly makes boring and ramping into metal a bit sketchy.

8

Thanks for the logs,

I’m a bit confused that the G-code alternates between G18 (ZX) and G17 (XY) work planes, is that intentional ? (which post-processor are you using ? just being curious)

VIsualizing CM logs in ncviewer, there does not seem to be any weird G-code move that CM would execute,

image
image1826×880 177 KB

And if your zeroes are still ok after this happens, then no lost steps or tool slippage, in which case…I’m out of ideas :frowning:

This though:

Given you setup for this job, is there any chance that at the precise location where the Z axis retracted before it travel to the “final” location, it collided with the top ? I guess not or other retract moves would have not it too, but since I can’t visualize your setup, I’d rather ask. No clearance issues of any kind in the vicinity of where the stock was mounted ?

1 Like
9

Thanks again for your input.

I’m using the “Carbide 3D (Grbl) / carbide3d” post-processor with the default settings from Fusion360. I’m not sure why it keeps switching work planes, I guess it just automatically does that. Regarding any clearance issues, I’ve ran cuts before with this same exact roundstock and workholding, so I would assume that clearance wouldn’t be an issue. I’ll try running the same g-code again and see what happens this time.

10

So running the exact same gcode again worked just fine… If anyone has any thoughts as to what’s doing on, your input would be greatly appreciated!

1 Like
11

Just a thought, is it possible that your z axis is binding on occasion while traveling upward before going into position for the next pass. That binding in the upward travel may cause the loss of a few steps and put the bit in the wrong starting position for the downward movement. I think I’d pull the z belt and check that the z travel is smooth from top to bottom. Also would be a good time to check those pulley set screws to see if they are where they need to be and tight.

12

Interesting idea. Thanks. I’ll check that.

13

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.