Odd Problem with Repetier on long troichoidal cuts

New Home Forum Mostly Printed CNC – MPCNC Troubleshooting – MPCNC Odd Problem with Repetier on long troichoidal cuts

This topic contains 12 replies, has 4 voices, and was last updated by  Simon Miller 6 months, 1 week ago.

Viewing 13 posts - 1 through 13 (of 13 total)
  • Author
  • #41602

    Simon Miller

    So I’m using an old Toshiba laptop and the electronics package that comes as the kit from here. Estlcam V9 to generate my toolpaths and Repetier to cut them. I’m using the base firmware with an LED but no SDCARD that I can find.

    I just started into aluminum and now that my cuts are getting much longer (over 45 minutes) that Repetier visibly slows down as the program continues. In the beginning the commands are flowing past on the log window too fast to read and the troichoidal cutting is nice and smooth. The ETA counter counts down fairly close to the actual clock.   By 25 minutes into the cut the commands are visibly appearing on the log window one at a time, the cutter head is lurching in almost a trapezoidal pattern and the ETA counts down more and more slowly. Often it will take 3 to 5 real time minutes to get through one ETA minute.


    Looking at the TaskManager during a cut, with absolutely nothing else running I have ~60% CPU usage, less than 30% memory usage and essentially 0% disk usage.


    Has anyone else run into a problem like this? Short cuts are fine, running for 10 minutes or so everything runs as normal. I don’t think the stepper drivers are getting hot though I’ve tried adding a fan on them to no result. It really looks like Repetier is just sending each command with a long delay.   I’ve looked through the Repetier forums and plenty of people are doing multi day prints so I don’t think it’s an inherent failure in Repetier, could it be my settings?





    Interesting. 30% memory for the whole system, or is all that in repetier?

    One big difference between printing and milling is that to repetier, all the movement is travel moves. It’s possible they are assuming no one will travel 150MB worth of gcode before printing something, and they are doing some poor memory management, causing some huge object to be copied in between each gcode send. I’m saying this, trying to guess what they are doing. I’m a software engineer and that’s something I would look for. Trochoidal milling adds a lot more lines of gcode to a file because the gcode for a straight line was just two lines, one for start and one for end. Now, it’s probably several arcs for each circle, which would be thousands of times bigger.

    I would take this to their developers, and report it as a bug. I’d include how much memory repetier was taking, and if there’s a way to see memory I/O (not hardisk or network I/O), I’d include that in the report. You could also provide them with the gcode file, since they won’t have a way to replicate it easily. Maybe they’ll give you some code to test out, or it could get fixed in their next release, or they will say, “I don’t care” and never fix it.

    As a workaround, if you have the LCD, you could run from there. Or you could send the gcode using Pronterface or Pronsole: http://www.pronterface.com/

    Keep me informed. This is pretty interesting to me.


    Simon Miller

    That was full system memory but essentially all repetier. It was showing 225Mb for the repetier process.

    I didn’t realize that’s how repetier treats milling, I also was running the Z oscillation from Estlcam as well as troichoidal so it was a massive file. I’ll turn that off and try a newer laptop to see if any of that matters.

    If no results from that I’ll give Pronterface a try, I started with Repetier and haven’t used anything else. My LCD is literally a bare LCD wired up through a breadboard so I don’t have any storage on that, is there some way to run a mill straight from the Arduino code?




    If no results from that I’ll give Pronterface a try, I started with Repetier and haven’t used anything else. My LCD is literally a bare LCD wired up through a breadboard so I don’t have any storage on that


    Just a thought.

    is there some way to run a mill straight from the Arduino code

    That would be interesting. I’ve been wanting to investigate something like that for the ZenXY/Sandify, but I doubt it will have enough memory for a large program like what you’re running. You could also try running octoprint from a raspberry pi, or pronsole from a raspberry pi. It doesn’t need a supercomputer, it’s just a bug in repetier. That’s all based on my guess, at least.

    You could also try universal gcode sender:


    Simon Miller

    First off thanks for the heads up on the LCD. I didn’t realize they were that cheap and easy. I have one on the way now so I can test with the SD card when it gets here.

    I went back and monitored my task manager while I was cutting. It does appear to me to be a Repetier memory issue. At the beginning of the cut I’m seeing ~25% CPU and 90MB dedicated to the Repetier process. By 15 minutes in to the cut I’m seeing 45% CPU and 200MB dedicated to the Repetier process with the machine just beginning to lurch. I’m going to submit this as a bug and see what they say.


    Until then I’ve downloaded Pronterface, gotten it connected and able to manually move the gantry in the correct directions and speeds. At the moment any GCODE file I try to open just says “This print spans 0.0 in X and Y and will take 0.0 minutes to complete. Something isn’t right there.

    I guess my next step is to dig out the raspberry pi and see about getting that to run. Maybe tomorrow after work.

    Thanks for the help up to this point, hopefully I’ll get this straightened out and back to cutting soon.



    Yeah, since there is no extrusion, pronterface thinks, why would you print that?

    I was hoping the other utilities that PrintRun has wouldn’t be so smart. Specifically the pronsole. I should probably have tried it myself before suggesting it.



    I ran some milling gcode from http://www.v1engineering.com/forum/topic/random-pauses-during-a-job/ using pronsole.py. It was pretty easy.

    ./pronsole.py Armv1.gcode



    I had to jump through some hoops to get it installed and make it support 250kbps, but I think if you have pronterface working, it’s probably going to work right away.


    Simon Miller

    I’ll give that a shot. I have been trying to estlcam up and running correctly as another test while I wait for the LCD but I like this idea. Try and reduce the variables as much as possible.


    Kevin Lopez

    I too am trying to ditch repetier. Never had issues 3d printing but milling has got me getting mixed results. I ordered my LCD. For my setup it makes sense anyways to use an SD card. The PC I run is a makeshift desktop made out of a 10 year old laptop.


    Simon Miller

    So, pronsole worked great with one small caveat.

    I tested it with my original file, no slowing and no excessive memory usage.

    I then tweaked the design in Estlcam to make it a bit more efficient and added a finishing pass. The finishing pass is with a new tool. Not physically a new tool but a new tool in Estlcam that is my same 2 Flute endmill but non troichoidal.

    The program ran just fine up until the tool change. It pulls the Z axis up to the clearance plane then just repeats “Paused for user” endlessly. I tried sending an M24 thinking that’s a resume. I tried actual “resume”, I even tried “off”. No luck. I just got an endless string of “Paused for user” until I finally hit “Exit” and killed the whole print/session.


    So, pronsole was sort of a success. I like the command line interface for cuts I’ve seen before. It doesn’t have a memory load issue. If I can figure out how to get the tool change thing to work I’ll be in business.




    As long as it’s the same tool I just edit the gcode and remove the pause command.



    You can type “help” and it will list a bunch of things you can get more help with, like “help print”. I would guess it would have a way to fix it, because there are reasons to pause a print, like for a color change.

    At any rate, this was a good test. It seems like the problem really is repetier. Maybe this will solve Kevin’s problem too.

    I really like pronsole, but I’m sure it won’t be for everybody.


    Simon Miller

    Oh no, I wasn’t dogging on pronsole. I like it quite a bit actually. The command line is much cleaner to me and being able to define my own macros as I go is super helpful.


    After reading the Gcode a bit I’m beginning to think that the problem is that I didn’t understand the tool change sequence. It looks like it’s not waiting for a Gcode or Mcode at all. RAMPS is waiting for a physical button press completely independent of the code itself.

    Someone who has successfully done tool changes correct me if I’m wrong but I think once i get the LCD the button on that or the rotary will allow me to pass to the next line. I tried to figure it out by pin assignment and just momentarily ground that pin with a jumper but I’m not quite sure what pin it might be and don’t want to kill my board before the LCD gets here Monday.

Viewing 13 posts - 1 through 13 (of 13 total)

You must be logged in to reply to this topic.