I just recently finished my build, and after running a LOT of sharpie drawings, I was confident enough to put the DW660 on the end instead and start cutting wood. I ran two cuts last night. One at the speeds provided in the ESTLCAM walkthrough provided on this site, and the other by dialing the speed back to 35% using the feed rate control in Repetier. On the first cut, the cut made it a few letters in and dove deep into the wood. It maintained the same depth once it plunged. I stopped it and looked over my z-axis thoroughly. No slipping. I then left the tool off, kept it well above the table, and watched the entire print. It didn’t once plunge like it did previously. The last print, at 35% feed rate, made it all the way to the very end, and I finally saw what was happening. The CNC was making some small circles and attempted to immediately retract when finished. It got stuck on the side wall of the wood (I assume from not being done cutting yet and trying to retract) which caused the Z motor to skip almost the entire 5mm retract. Thats where it plunged deep into the wood when it made the 5mm step back down. I think a few other people have had this issue too, but I haven’t really seen a fix.
My initial thought was I wish I could use the “dwell” feature in Gcode to tell the machine to wait X seconds before and after every z movement. This would allow the bit to finish a good clean cut rather than still having pressure on the side wall during the retract. Does that sound reasonable to anyone else? Or is there a better suggestion for a solution? I don’t think it’s possible to have ESTLCAM add these waits in, but I may just write a program to run the gcode through that will add the waits before and after each Z. I appreciate any feedback!
EDIT: realized I had a video of the first run through (regular speeds set in the ESTLCAM walkthrough). After watching this, I’m not sure if waiting before retract would’ve helped for this one. It looks like it just completely skips the retract, even though its in a wide open, precut area, and cuts through the material on its way to make the next letter. Then it gets there, and plunges another 5mm (right at the end of the video, when I frantically dash for the “Kill Job” button.) I used the same Gcode for both runs, and it didn’t plunge at this spot the next go round, so I’m 110% sure its not a gcode issue. Any thoughts?
The most common problem is seriously over tightening of the anti backlash, It is best just to take it off. There have been a few other issues but usually it is the anti backlash being used improperly. Try that and let us know.
I had problems early on with the printed rigid coupler not holding onto the stepper tightly enough. It slipped a lot. I replaced it almost immediately with an actual metal one. You can check yours by watching the stepper motor at the point when the tool is supposed to retract. If the stepper turns but the allthread does not, there’s a problem. The allthread should turn with the stepper at all times with no play at all.
Thanks for the replies! I haven’t had a chance to run another cut since removing the anti-backlash spring, but I’ll post back ASAP once I do. Hopefully tonight. Karltinsley, I was actually thinking that this would be a potential problem when I was building it, but mine fit together ridiculously tight before I even added the screws to tighten it so I decided to wait. Do you have a link to the part you used to replace though? I’m unsure of what size to order, etc. Thank you!
I removed the backlash and tried to cut again. This time I also had ESTLCAM create pockets for all of my cuts, which seems like it would greatly reduce the stress on the tool with all of the extra small cuts. It still got stuck on retract and plunged. I didn’t hear the Z axis stepper skip (these steppers are pretty strong, so they’re definitely audible when they skip).
I don’t think my Z motor coupler is sliding either, as it is a really tight fit, and then I tightened the screws too. Do you have any other suggestions I might try before I try to print the new middle assembly and see if that fixes it?
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…
Second person to find this issue, are you using the most recent version of estlcam? I think Christian replied on the forums about this and maybe he said he fixed it, not sure. I’ll look around for this, it might have been in an email.
Oh good, so I’m not alone then actually. Makes me feel more sane haha. I am using the most recent version of ESTLCam. The old version actually started crashing before it even opened every time, so I uninstalled, and did a fresh download a re-install from the site yesterday. So it should be the latest.
Okay I had a job go bad the other day from the same issue. I just reinstalled estlcam and it erased my values for some reason. So I will be playing with this. His change log says he fix unequal axis, but I don’t see a setting for this at all.
So the easy work a round I think is to slow your max speed of your z axis in the firmware. It should not be able to go above this. The way I set the firmware we are a little below max, set at 8.7 and max is 8.9 I think. but I think I will lower this to stop this from happening if I can’t find the other rapid setting. I am not concerned with speed I just want good parts.