Machine Stopping Mid Cut

I have done a fair amount of cutting with my MPCNC so far, but i keep running into the same issue. When i do longer cuts, my machine is just stopping mid cut and the board disconnects from the computer. I have used repieter host and pronterface and both have done the same thing, so now i know its not the controller software. I have also ran the same code several times and it will stop in randomly different times in the cut, so its not the g code. I have ran code on two different computers, windows 7 and 10 (The windows 7 machine seems to do it worse/more often, but it has happened on both several times). In the controller software it will say that it has lost communication to the board. If you disconnect and reconnect via the software it says it cant find the board as if it weren’t plugged in. If you physically disconnect the board USB cable and plug it back in, then you can connect to it via the software. This is becoming a major problem because if i want to do a long cut for a customer on a nice piece of wood or a sign that is already constructed and it stops mid cut than its ruined. At least i haven’t figured out how to successfully start back where it stopped after it does this. I am using a 10ft USB cord. I bought everything from the site. I am getting pretty frustrated with this because i do something different and i think i might have it fixed. Then i run a cut and it does it again and i loose more and more faith every time. Its becoming impossible to depend on. I would appreciate any help i could get with this. I’m willing to try a different board and or the lcd controller if necessary. I am also going to try the shorter USB cable, but i seriously doubt this is really it. Thanks in advance.

 

Andy

The usb could be picking up all kinds of interference, or just a little wiggle and it disconnected, or computer going to sleep?. If you are having issues get an lcd.

 

If you have any of your rapids wrong it can reboot it as well at random times. That why it took a year to figure that out for the group collectively.

Do the rapids need to be set exactly at the speeds you have posted, or should they not go over X amount? I say this because i checked and had the xy speeds in repetier set at 3800 instead of 3600( I believe it says 3600). Also in pronterface i had them much lower at 3000 and 100. I just put in an order for the LCD, if this solves my issues then it will be the best $20 i have ever spent. What about heat and the drivers? They seem to get fairly warm.

The x and y will choke above 120mm/s, the x depending on your screw will choke above 8.4mm/s.

If you are running pre-made gcode, pronterface or repetier will not limit your speeds it just runs code.

 

I have no information on your drivers, steppers or what you have it set at. If they are over heating they will just stop moving but the board will continue to run the code.

Ok rapids in estlcam are set correctly. Hopefully the LCD will take care of my issues. I haven’t changed anything with the board/drivers/steppers. Everything is as it was when i got it from you, I just didn’t know if driver heat was a known issue. That’s probably not got anything to do with my issue, since the board does not continue to run the code when this happens. Sorry to bother you Ryan.

Thanks,

Andy

No bother, packing orders.

The drivers and steppers can handle some heat, but keep an eye on it and test it if you get a chance.

What are you describing is exactly what happened to me. I feel your pain, I lost so much material due to it pausing in random spots. I did get an LCD and that fixed it for me, no more issues after days of hours of use. My drivers get hot as hell and they still manage to get the job done. Their lifespan will probably suffer but I am feeling confident in them.

Wow so glad to hear some one else going through the same thing and that the LCD took care of the problem! Looking forward to gaining confidence back with the machine.

 

Thanks,

Andy

I had the same issues as you, but with a delta printer (same scenario, though - RAMPS/Ardiuno, USB cable, Repetier, etc…). Ended up being a small beer refrigerator I had on the same power strip as the PC and printer, with the USB cable running along the rear. Every time the compressor would kick on, I’d lose the USB connection until I unplugged/re-plugged the USB. Moved the fridge and got a shielded USB cable. Never re-occurred since. So, it very well could be some sort of EM interference or a power dip/spike from an unrelated piece of equipment.

If you are running this from a laptop Windows will kill USB ports to save power. Go into your power settings and disable all power saving and look for USB selective suspend.

1 Like

I see that this usb selective suspend also applies the same to a desktop, because it was enabled on mine. I ran with both a laptop and desktop. I have disabled it now. This seems to be exactly what was happening. It acted just like the computer was killing the port. It also makes sense because the windows 7 desktop was always worse than the windows 10 laptop. Potentially due simply by the shut off strategies of the two different operating systems. I haven’t thoroughly tested this yet but this makes more sense to me than anything.

 

Also just to add, I have had a few instances of repeiter doing strange things. The application has hung a couple of times on me. For me it also does odd things after using emergency stop, then trying to run the next code without restarting the program. If I restart the program it doesn’t have those issues. I started using pronterface and I’ll never go back. Although it’s very basic graphically, it just works smoother without any of the issue I had with repeiter.

 

Thanks,

Andy

I’ve found emergency stop to do weird things no matter what kind of device you are using… the MPCNC, 3D printers, etc… Goes crazy with Cura, Simplify3D, and anything else I’ve used. :slight_smile: I just take it as a given and will reset everything if I have to use the stop button (either on the Arduino itself or in software).

Do you have any other devices on the same circuit? In our fab shop in AZ recently we had a plasma cutter keep losing connection when it was pulling data. It has a serial over ethernet device that connects to it. Turns out the circuit that the device was on also had a welder and grinder connected to it… so when those tools were being used weird things would happen to the serial device and data would stop. Had an electrician run another circuit and it cleared up that mess.

Actually battling this issue right now with a similar setup in out Houston facility, a single job pulls fine to the plasma cutter, then any jobs after that pull half of the Gcode and then it just stops. No welders on that circuit though… Fun stuff!

No one complained about repetier until a few weeks ago (AFAIK). I think they messed something up in their latest release, and I don’t think CNC work is part of their test suite, at least not the big jobs.

I thought pronterface didn’t want to run CNC jobs though, because it made a “helpful” check on the print size, and determined it was 0x0x0. Did you do something to get around that?

Yes, its the zero after the letter of the command that causes the issue. So M03 needs to be just M3 or G01 needs to be G1. I simply went into Estlcam under setup/cnc programs. Under “texts” go through all of the sub menus and delete the zero’s right after the M’s. Then go into “commands” and delete all the zero’s right after the G’s. That completely solves the issue.

What! Nice find. I Probably need to add that to the setup instructions or see if Christian will change it in the next update.

I need to get confirmation or test it first I guess.

Works perfectly for me…someone else should verify though…the changes in estlcam don’t effect the use of repeiter host. It appears to read both G01 and G1 etc. as the same thing.

That’s a strange result. I’m looking at the Marlin firmware, and it is handling leading zeros just fine. At least it should be… If there is a problem, it wouldn’t execute the line at all, or error. It wouldn’t lead to dropping the motors at the very end. I’m sorry, but I am suspecting something else is up here.

I have 0’s in all my gcode and it doesn’t seem to cause an issue…

Obviously some misunderstanding here, sorry…the post about deleting the leading zeros is referring only to the question about the pronterface workaround. This simply solves the issue with it thinking the size is 0x0x0 and will let you actually run the code…this has nothing to do with any of the other issues I had previously mentioned…really sorry for any confusion.