Fun with runaway x-carve - Solved

So after several successful carves, I experienced something last night that got pretty lively and fun. I had started the x-carve on about a 3 hour carving project on a small block of (soft) wood. After making sure everything got started good, I went back in the house to watch some TV. Yes, I’m sure there’s somewhere in the manual that says you should never leave your x-carve unmonitored, but I’m sorry…I’m not going to sit there for 3 hours and watch it. :smiley: My garage is right on the other side of the wall of the TV room. About an hour in to the carve I hear all hell break loose in the garage. I went running out to find my x-carve had apparently gone crazy. Instead of carving the round wood mask I had set it on, it had suddenly dug the bit about halfway in to the 25 mm thick piece of wood and was trying to draw random squiggly lines all over the place…at an 800 mm feed rate. Bit was chattering like it was about to break and the x-carve itself was about to jump itself right off the workbench. I quickly slammed everything off just in time.

So, I ran the g-code though a preview as I always do and of course this little random carving was not in the original design. X-carve hooked up to a new laptop computer with Windows 10 and it never goes to sleep when carving. It was the weirdest thing I’ve seen so far. Robots with a mind of their own! :smiley:

Well, it seems I have a much more serious problem than what I thought was a simple one time glitch. Ran another carving this morning (different model than last night) and at roughly the same point in the carve, which was around 80% complete on the roughing, the X-Carve developed a mind of its own and started slicing and dicing the model at random places. Fortunately I happened to be there when it happened this time.

Since nothing is showing up in the G-Code preview, I’m assuming this is a problem either with UGS (I have the latest version) or the controller itself. I’d appreciate any advice on how to troubleshoot this as the X-Carve is basically going to have to sit idle until I can figure out the problem. If it matters, the only thing different about these last two attempted carvings and my first several successful ones is the time involved. Those first successful carvings were all very short, like about 30 minutes for roughing and 30 minutes for finishing. These last two were processed to be much longer, about 2.5 hours for roughing and 3 hours for finishing.

Did your computer go to sleep during the carve? Do you have any type of power management set up on the computer? Specifically the USB ports…

Thanks for the reply, Erik. I just went to double check, and there’s nothing set anywhere that puts the computer to sleep/hibernate. I made certain to do that on purpose when I first set it up for use with the x-carve. When I open up the laptop the UGS screen is still up and happily pushing g-code to the controller.

What version of windows are you running?

Windows 10 - 64 bit

Double check under device manager, check the hub properties, power management tabs, make sure the box for windows to turn off the port is unchecked. I had this problem early on.

1 Like

Wow, Erik, you may have just solved this for me! I followed your instructions and went in to the USB properties and sure enough under the “power management” tab there was a selection for “allow computer to turn off this device to save power” and it had a check mark next to it. I didn’t even know this setting existed! I’ve turned that off now and will go back and try to run another carve to see if that alleviated the problem. Thanks again!

Good luck… That little check mark bit me as well… Enjoy.

Windows 10 is just rude. A while back the damned OS figured that it was time to suddenly reboot for updates - mid carve!

Well, despite Erik’s helpful advice the same thing happened again (completely different file this time) at almost the exact same spot of approx. 80% complete. I went back in to the USB driver to make sure the “sleep” box didn’t somehow get checked again by the system, but it was still off as I had left it. So, it would seem to not be an issue with the USB controller on the computer end. So now I think we’re narrowed down to either an Arduino driver issue or an issue with the controller itself. I took a screen shot of the info on my Arduino driver:

Maybe it’s not the correct one or there is an updated version somewhere?

Are you sure you are not just losing steps on the z axis?

Did you disable all the USB Power Managements? There may be several. Open them up one at a time and look for the Power Management in the menu and uncheck them all.

Allen - I’m not sure what the means to “lose” steps on the z axis? I was watching the machine the last two times this happened and it’ll be carving just fine and looks like it’s almost done and then suddenly the router starts running off in random directions. Both times what preceded the carver going bonkers was it would suddenly run right through the edge of the wood towards the front of the machine then it would plunge back in to the wood and start carving the hell out of it all over the place. picengravertoo - I’m pretty sure I disabled all that I could see, but I’ll go look again.

While there appear to be four USB controllers, only two contain the ability to change “power management,” which I’ve done. Here are some more screen shots so you can see what options I have available:

Forgot to add one more thing that’s odd. The first time this happened it was with a file that was set to take about 2.5 hours for roughing. The second file this happened on was set for a roughing period estimated to last about 1.5 hours. In both cases, the x-carve went nuts right at about 80% complete.

Losing a step is shortcut for saying that the controller commanded the spindle to move and for some reason the spindle did not move as expected. So after that, the controller “thinks” the spindle is in a different location than it actually is.

Most of the time a lost step is due to a mechanical issue. For the X and Y you may have the belt to tight or loose or one of the drive pulleys may be slipping on the motor shaft.

For the Z you may also have a loose pulley (either on the motor or attached to the threaded rod) or you may have mechanical binding as the delrin nit tries to move up and down the threaded rod.

There is also the possibility that the controller voltage to any of the motors is either too low or too high which can cause a lost step for different reasons.

The result of losing steps on the Z will cause problems that sound a lot like what you are describing. If the controller “thinks” the Z axis has retracted out of the material when it fact it is still in the material will cause a lot of excitement when the controller tells the spindle to perform a rapid move to a new location.

I know this because I had the same exact problem, my Z motor was loosing steps because the controller voltage was a bit low and I also had a pulley on the Z motor shaft slipping. Between those two problems I caused the bit to embed itself into the wasteboard all the way to the collet once and then ruined more than one project before I got both problems fixed.

Sorry, Angus, must have copied the wrong link:

what object are you carving? Where does it fail?
what is you full software chain?

there’s so much that can be the cause, i wouldnt get blinded by win10 issues…

Hi Allen - Thanks for that additional info. This must be what I read about in other places here when people say they had to adjust their “pots?” I think I remember seeing those adjustable looking thingies when I was assembling the controller. Sounds like it could be pretty problematic and time consuming to fiddle with those settings until everything is perfect. :confused: What I still don’t understand is why I was able to run four “short” projects just fine but these two long ones got screwy. I understand what you’re describing to me, but if that was the case with the small ones as well, they should have looked “off,” but instead they came out perfect. It also doesn’t explain why this would happen so suddenly. On this second failure I happened to be standing right over it when it happened (because I was expecting it to end very soon). Everything looked perfect and just like the g-code preview showed that it would, when all of the sudden it’s liked somebody flipped the “crazy” switch and it just started doing its own thing.

xfredericox - Can you explain more what you mean by “full software chain?” I’ll look it up for you if I know where to find it. Are you asking for a rundown of all the different software I am using to get the model to the x-carve? As far as what I was carving, one was a portrait and the other was a wood mask. Both failed at about the same spot, despite being different sized as far as time to completion.