Random Pauses during a Job

I use repetier (the new 2.0 version) and during my cuts, everything just pauses and there is no recovery so I have to start from the origin and try it all over again. My cuts are coming out beautiful but they nearly never finish because of this. It’s not a tool change, because the whole system gets unresponsive (no start signal forcing start)

This started happening ever since I moved my setup to the garage, prior to then this never had an issue. At first I thought it was the sketchy laptop I was using so I switched to an even more sketchy computer setup. No luck there, the computer isn’t the problem. I downloaded an older version of repetier, nothing.

Changed the baud rate from 250000 to 115200 and changed the bits per second from 9600 to 115200 in device manager.

Thought I was running out of current on my outlet since I had the vacuum, dw660, and a bunch of other stuff. Tried running the gcode without anything on just as a test and it still paused in a random point.

This is a connection issue of some sort. I am ultranoob at software so anyone who knows anything about the ramps 1.4 or repetier can chime in.

How do you know it is pausing and not rebooting? If your z rapid/plunge is too fast (above 8.4mm/s) you will reboot the arduino randomly, is why I ask.

Well on repetier and estlcam I have my z rapid to 400mm/m so well below the limit. I have to unplug and plug it in like 3 times to get it to finally register again.

Could be a bad USB, but running from the SD card is going to eliminate a lot of guesswork.

Also, (((I might be the only one that has this problem))), check to make sure the gcode is complete. I will transfer a file to the SD, and run it, it will stop, and then I will be very confused until I look at the gcode, and realize it is just missing half the file. I think I’ve only had that problem with slic3r though, because it writes to the file as it’s making it.

It stops at random points along the toolpath though, which tells me its not able to finish due to a connection issue. I am going to get sd card support, it’s not worth risking an unfinished toolpath. Would something like this work?


It should, but I think you’ll need new firmware because that isn’t the same LCD as the one Ryan sells.

Did you try a different USB cable? Octoprint troubleshooters are always telling people to try a different USB cable.

Maybe you could try it without the bit, and without the tool on, just to troubleshoot it without ruining anything.

Make sure your power cables are well attached on the ramps.
It is possible that the power disconnects briefly, so your arduino shuts off for a very short amount of time, enough to mess up everything. Check all your wiring also for possible short circuits.

Could also be some noise induced by your router motor or your vacuum cleaner, but less likely.

Wait until you can try the SD card before messing up with the USB setup

Funny that noise is mentioned, because this can be a real pain of an issue to diagnose. A few years ago I had a little refrigerator in my shop (beer!) next to the PC, with the USB cable going to one of my printers running behind it under the workbench. Kept experiencing all kinds of random disconnects with no real pattern I could see based on what was going on with the printer or computer. Took a bit, but then I realized that anytime the compressor powered on while the USB connection was active, it would halt and reset the Arduino. Re-routed the USB cable and moved the fridge, problem solved.

Moved the fridge closer to the workbench right? Seems like the best solution, anytime the arduino resets you can grab a beer while you get ready to start again.

I can’t believe you figured that out, that would have drove me nuts .

Yeah maybe it is my beer(just kidding don’t call the police). I tried a new USB cable and it hasen’t stalled yet. Only did one test and it didn’t cut. Weird because its an unshielded cable so you would assume if it were interference it would be worse.

You are correct on the fridge placement! In reality, it was just random chance that I noticed the connection. I happened to be standing in front of the delta printed hypnotized by the movement and watching it print right when it halted. I also heard, at the exact same time, the click of the compressor kicking on. Thought it was a long shot, but I unplugged it for the day (warm beer - boo) and had no further resets on that machine. Moved things around and the problem was solved. I suppose using a shielded cable may have also solved the issue, but I did not have one handy at the time!

Which power supply do you have? I had a funky one that caused that issue. Horrible solder points inside, replaced it and haven’t had that problem since.

Sorry Barry, never saw your post. I am using the one from vicious1. All my electronics and stuffs were bought almost a year ago. It may be the PSU, I will test that tomorrow.

I am getting the issue again, it is really bugging me. Pausing mid cut is so frustrating cause then that part of the aluminum I cut is pretty much trashed, and it isn’t that cheap. I try to start the same gcode again from the same origin to save some stock but it’s not fun

Verified it wasn’t my USB, used an un shielded longer one and it worked for a few weeks. Now I just got my huge barstock of aluminum and it is back. Maybe it is interference? Repetier basically crashes when it happens. If it were JUST a lost signal you would expect that everything would halt, and the program would still be functioning? Not the case here fellas

“no signal detected forcing start” when I try to reboot.

Where are you seeing that error message?

In your first post, you said the whole system freezes. You mean the computer or what? You don’t have one of Ryan’s LCDs yet, do you?

I am suspicious of repetier now. There was another post yesterday where repetier was using increasing memory and CPU when the gcode got bigger. I’m sure your gcode is huge. It may be the same problem, but manifesting in a different way on your system. You could have a look at task manager when it’s running.

An LCD would help a lot here. The zenxy page has a link to Ryan’s or one on Amazon that’s like $10.

I will try using printrun pronsole later today sometime. If not that, then I’ll try the other gcode sender I saw. Can you post you gcode for me? Or pm it to me?


To check the power supply, bend the AC in wire at the power brick. That’s where my problem was. When I broke the brick open the solder points were barely soldered.

I see that error message when I try to reboot it right after it halts. Only after 3 times and some unplugging and plugging back in does it finally tell the normal expected callouts.

Just makes no sense, used to work forever upstairs with the same hardware, then again that was with 3d printing gcode.

Here is the gcode it’s freezing on. Note that again, it freezes in random spots so that leads me to believe the gcode isn’t incomplete. Also, I didn’t get any freezes on a gcode where I made 3 pieces at the same time, and that gcode was even bigger than this one! Gah, computers!

I’m going to just get the screen and see if that helps. Will be another 3 days.

Armv1.gcode (2.42 MB)

I’m really guessing here. It’s hard to tell what’s happening from here. But memory problems in repetier could end in connection problems. Broken connections are hard to recover from, so those error messages might be less than useful.

I don’t have a windows machine, but I used pronsole.py to run your Armv1.gcode on my sand machine. I used a raspberry pi to run it. It ran to completion. It doesn’t really prove anything, except that you have a way to test without trusting repetier, if you want.