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.
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. 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.
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.
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.
Oh, I see. Thanks for the clarification. That is interesting. I wonder how hard it would be to fix that in pronterface… I’ll have to look into that… Meh, I’ll just send a bug report. Maybe they’ll just fix it.
HELP! I am now experiencing this same issue. Running the LCD Display from V1, DW660 Router, Rambo 1.4, ESTL Cam, and Craftsman Shop vac cutting WilsonArt Solid Surface. Cutting from file on SD card.I use dual end stops with a fixed jig, so I estop after every run, re-zero the Z, startup, home XY, then start program from the SD Card. Have run this same program successfully many times. Ran it yesterday fine. Ran this morning fine (another part) Started another part right after the first one today and is Stopped part way in and sits there. Tried again and it stopped again at the same spot. All this cutting from the same 1hr 53m long program. A few weeks ago I had the same issue, and it stopped at different locations. Previously reported the gCode from ESTL Cam just to be sure, and did the same thing. It seems like it only happens after I have already done one cut successfully. Then it pauses on the next one.
i saw the earlier post, so yesterday before starting, I made sure the board power is from a different circuit in the garage than the circuit feeding the router and the shop vac.
Can you tell if the electronics are rebooting, or are things just hung? If you don’t know, you could record your LCD display using a cam of some sort. Could swap out the power supply. A weak power supply might cause the problem. Bad or flaky SD card might result in this behavior. I’ve not used it before (and am away from my MPCNC so I cannot test it), but there is an M111 g-code that outputs additional information. If this information is sent to the LCD, then it might allow you to see what error is happening and/or what line of g-code it is hanging on (assuming the problem is not a rebooting control board).
And you might use some non-cutting time to run your program in air to see if you can reproduce the problem without wasting stock.
Power supply measures 12.5VDC when off and during operation. Is there something else to check on the PS? Cutting Air now to see if it stops at the some spot.
I don’t have any special knowledge, just brainstorming. If there is elapsed time on the timer, but everything is frozen, that just about rules out power issues like a failing power supply or an intermittent power wire issue. The control board is not rebooting. SD card issues are the only thing I can think of that matches the symptoms. Note if the M111 g-code causes errors and/or commands to be output to the LCD, it might tell you something. Look at Error level 1 or 4 or combine them for error level 5. If you can reproduce it cutting air off a new SD card, and M111 does not report to the LCD, then I’d try sending the file from a computer using Repetier Host. You definitely will get the information from M111 using Repetier-Host.
Jeffb3 mentioned on another topic earlier today that he has seen problems with EMI interference when using the SD card, and I thought that was another possibility for your problems. If the noise is causing your data to be corrupted, then Marlin could hang based on what it is reading. The only thing that does not fit is your hanging is happening in roughly the same place. I would expect a more random hanging if the issue was noise. While Jeff did not specify, adding shielding to your LCD cables might solve such a problem.
I am running the GCode file directly from the SD Card in the LCD. I cut air yesterday with no stoppage. I swapped out the SD Card for the one that works with no issue on my 3D printer and am running a test cut now.
Here is a photo of the board and LCD wiring with the plexiglas cover removed. Do you have any suggestions on how to shield the LCD cables?
I’m just a hobbyist and have only shielded a cable once, but from my reading on the internet, shielding is simply wrapping something in metal and then grounding that metal. Based on Jeff’s comments, it appears that the cables running from the display to the board are the potential issue. So if it were me, I buy some copper tape, maybe something like this, and solder a wire on the end of that tape. Next I’d wrap that tape around the suspect cables and then wrap some duct or Gorilla tape around the outside of the copper to both protect the copper and to keep the copper from shorting anything. The wire would then need to be connected to ground. You could connect it to the ground wire of your power supply, or if there was a Dupont connector on the end of the wire, plug it into any of the many unused ground pins on your Rambo board.
Sounds like good advice. if this issue crops up again, I will do just that. For now, I might have found the problem…I am a little ashamed to say it, but I realized that I have never lubricated the Z axis lead screw. I just ran a complete 2 hour run with no issues after applying some lube to the lead screw. I was setting up to do the test cut with the swapped out SD card, adjusted the Z manually, and realized that is was not that hard to move before. Ugh. Mechanical Engineer forgetting to do his own maintenance and first blaming it on the electronics. Will let you know if it crops up again.
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).
