Home / Forum / Troubleshooting / Z axis sticks, plunges deep into material / Reply To: Z axis sticks, plunges deep into material

Profile photo of RobertRobert
Post count: 4
#13339 |

So, I finally got time to spend all weekend trying to get this to work. Just got it working a minute ago, so I wanted to post back in the off chance someone else ever comes across it with the same issue. I checked the stepper driver voltage and it was low at about.43, so I moved it to .5 as suggested. No luck. I also tried taking the DW660 off and printing a mount for my Dremel 4000, thinking maybe the 660 was just too heavy or something. Still nothing. I added some white lithium to the Z rod, as it seemed it was getting a little bare. That didn’t help either.

At this point I was getting desperate, so I resorted to looking at the gcode. It seemed to always have an issue in a select few places during the same print, so I enabled the “Send” in repetier logs and waited for the issue. It turns out ESTLCam has two things that I think were causing my issue. One is you can only set the Z speed for a plunge. For retracts, it always uses the feed rate of X and Y. I was using the startup values recommended as 900 for X and Y, and 180 for Z. Reading through the gcode, I noticed that it was performing retracts without setting the speed to 180, then it would set the speed to 180 for plunges. I ran my machine a few times up and down out of the material, no issues even as high as 1500. And most of my retracts at full speed during a print worked fine, so this didn’t seem like it could 100% be the problem. I still changed this because I’d rather my Z axis moves all be at a slower speed. It isn’t moving that far, so it isn’t terrible on time to just run it like that.

The other thing I noticed is ESTLCam will generate lines of code like this: (current position of the bit would be Z of -3.00 and some X and Y not equal to the values about to run) “G00 X55.4597 Y71.3527 Z2.0000” this essentially causes the bit to move in X and Y while performing the Z retract. If there is uncut material there, it can cause a snag, which was causing my issue. So I wrote a program that takes the gcode created by ESTLCam and changes all Z moves to 180 and separates out any XYZ moves and turns them into two separate moves of Z, then XY.

Anyway, It’s working now, so I’ll just have to add this extra processing step to my process. Not sure why I’m the only one with this issue, or why ESTLCam would have an XY move at the same time as Z retract, so maybe my gcode understanding is lacking…

  • This reply was modified 4 months, 3 weeks ago by Profile photo of Robert Robert.
  • This reply was modified 4 months, 3 weeks ago by Profile photo of Robert Robert.