Machine wanders off in middle of routing, then gets back on track sometimes?

Mostly Printed CNC - MPCNC Troubleshooting
#1

I’m not sure what to search for. I’m sure it’s user error on my part somehow. Sometimes during a “print” with my router in the MPCNC, it seems to get “confused” for lack of a better word. Sometimes after its little detour it gets back on track, sometimes it doesn’t. The detour typically destroys the workpiece. In this latest occurrence, the router lifted up to shift positions without cutting, but lifted higher than it should have; when it arrived at new xy, it went down the correct amount, leaving the bit floating over the workpiece as it continued working. A brief glance at the g-code file indicates that all the delta-Z values are identical, which I believe rules out Estlcam as the culprit, leaving repetier-server and the firmware, or a hardware issue. Not all “prints” are affected.

Software Versions:

Inkscape 0.91
Estlcam 9.011
Repetier-Host 0.75.1 running on Raspbian
Whatever firmware the RAMPS board shipped to me with

All of the plastic pieces were produced at my local makerspace, but all the motors, electronics, wiring etc were purchased from v1engineering.com. Tool mount is from thingiverse, everything else printed from your files as of a few months ago (includes better middle Z, but does not include “major update” parts with new motor mounts etc). No end stops.

Photos, images, estlcam and gcode files available at http://yumesoftware.com/bunny_failure.zip. At 27mb it’s too large to attach to this post.

I’m happy to provide additional information if you can tell me how to get at it. Any and all help much appreciated. Thanks a bunch!

#2

Your router is very large, and your z moves are more than 2x’s the firmware max. Try plunge rates of like 5mm/s not 20.

Your belts are at a pretty extreme angle, you are bound to get errors from this as well.

#3

Awesome, a place to start. Is there a list of the maximum rates for things so I can be sure not to exceed them? For the belts, I attached them the only way I could figure out how. Any tips for improving the angle? I am grateful for your speedy response!

#4

You have the X axis belts attached to the wrong point, right above it there is another mount hole.

You should stick to under 20mm/s x and Y and under 5 for the z. I would honestly start at half of those values to learn things so you don’t break anything. You are also using a very large wood router bit, You should try some actual endmill, with about an 1/8" diameter to learn with.

All of my videos have the feeds and speeds listed, probably start there to get an idea of an upper range for your machine.

#5

I’ve been playing around with a 1/8" end mill mostly. I just wanted to try some carving. I figured in foam it would be ok for testing. I’ll take a look at the belt attachment points tomorrow to see if I can figure that out, and I’ll slow things way down to see if that resolves the issue. I just don’t understand how trying to move too fast could cause the z to go too far up, or the xy to cut a perfect circular arc through the center of my workpiece on a mid-depth pass. I’ll take a look at your tutorials again for better rates to start with. Again, I really appreciate you taking the time to set me on the right path. You are awesome.

2016-08-30-18.20.35.jpg
2016-08-30-18.20.35.jpg1000×748 122 KB

#6

Trying another attempt with xy feed rate at 10inch/min and and z at 3inch/min. About an hour into a 4-hour program the router simply stopped moving. Looking at the console log in repetier-server I see things like the following:

21:27:16.476: Warning: Communication timeout - resetting communication buffer.
21:27:16.477: Connection status: Buffered:119, Manual Commands: 2, Job Commands: 5000
21:27:16.477: Buffer used:119 Enforced free byte:23 lines stored:6

After powering everything down and back up, I restarted the print, this time watching the console. Lots of things look fine, but sometimes I get errors like:

21:28:36.106: Error:Line Number is not Last Line Number+1, Last Line: 111
21:28:36.106: Resend: N115 G01 X17.9827
21:28:36.115: Resend: 112

and also

21:28:36.089: echo:Unknown command: “16”
21:28:36.090: ok
21:28:36.090: Resend: N117 M105
21:28:36.091: echo:Unknown command: “18 day 1”

Any idea what goes on here? Could it be related to the above described problems?

#7

Now that is really slow, You should stick to mm/s until you get the setting worked out. 1oin/min is about 4mm/s

Did your computer go into sleep mode, that will cause that.

#8

I encountered this hang about 80 minutes into a 4-hour job, so if it’s reproducible at that point it’s going to be a pain. I’m running it again now.

I’m not sure how to change the units involved. As far as I can tell it’s just an Estlcam gui setting and shouldn’t affect the generated g-code, right? I figured if slow was good, then reeeally slow was better. I can change the setting in Estlcam if you think it will make a difference.

The computer is a raspberry pi running raspbian. I’ve got a live webcam stream from it plus repetier-server in a tab in chrome watching the console output. As far as I can tell nothing is sleeping. No USB errors or notifications of state changes present in dmesg to indicate a problem at that point on the pi.

#9

There is a sweet spot to speed, too fast breaks things, to slow burns things. Yes there is a setting in estlcam.

Maybe turn off the web cam and extra stuff and just run a job barebones first. Trying to trouble shoot too many things at once.

#10

Sadly, I can’t stand in my shop watching a cnc job that takes 4 hours, so the webcam offers some amount of supervision and safety. I understand that it increases the potential problem space.

That said, replacing Raspbian and Repetier-Server with OtcoPi/OctoPrint seems to have resolved the issue. No more communication problems or random detours in the middle of prints. I went this direction after reading several threads on the Repetier-Server mailing lists where lots of people had similar issues for over a year and never got it resolved. Several people there mentioned switching to Octo resolving their problems, and it appears to have done so for me as well, at least so far.

Since the jobs do better now, I progressed to the point in the job where a tool switch was needed. The board seems to receive the M00 stop command and stops moving. I replace the tool, but after that I’m not sure what to do. There’s no resume button in Repetier-Server or OctoPrint to let it know I’m finished. The reprap page on g-code indicates that I should push the Reset button on the controller board when I’m done, but that seems to disconnect the cnc from Octo and abort the job, rather than resume it on the following instruction. I apologize if this is covered in the documentation or tutorials somewhere, I do not see it. Any ideas for this issue?

I am very pleased to be making progress, and my mind is full of awesome ideas to try :slight_smile:

#11

I haven’t used octopi in 3 or 4 years. If pushing the button n the lcd does not resume it I’m not sure how to do it. There are several octopi users here hopefully they can chime in.

#12

LCD? The only button I have is on the RAMPS board labeled “reset”. I do not believe I have an LCD in my current setup?

#13

Have you tried sending M24, it is gcode for resume print. Octipi might have it’s own command

#14

Sending M0 to pause for the tool change seems to make the board unresponsive. I’m going to try pausing with M25 instead, in the hopes that it will pause the print but remain responsive. What is up with this LCD thing? Another accessory I can buy to make life easier?

#15

Changing my settings in Estlcam to issue M25 instead of M00 to pause for tool change has resolved my second issue. At this point everything seems to be working great! Many many thanks for your assistance. Is there a forum post for peoples’ “first” projects I can share in once this job finishes? I’m so excited!

#16

Awesome!

Drop it in “builds and things built”.

#17

If anybody else is reading this later you can also try going into settings on repetier server and turning on ping-pong mode rather than switching to Octoprint.

#18

Thanks for the tip ualdayan. I should have mentioned that I tried that and it didn’t help for me, but hopefully it may help someone else :slight_smile:

#19

Another late-ish reply on the Repetier Server item. I saw exactly that sort of hang for quite a while in Repetier Server (on a pi3). I got past it by being on the latest version of the firmware from Ryan, but also turning off the options to “send updates to the LCD display” and turning off the temperature checks on the CNC. It really seemed to be hanging up when it would send messages through to show on the display, the firmware would get lost. The latest release that is on my MP3dp though seems to process them pretty well and could also resolve issues just with the firmware.

now I can run 4 hour jobs very reliably on the CNC.