Jump to content

Recommended Posts

Posted · Suddenly staggering after initially smooth high speed printi

I started this morning printing Yoda-lite. It started fine - running at F15000 (250mm/sec in Slic3r), going around like a madman, and the first 10mm printed just fine. (Edit - 0.08mm layer height, so the 250mm/sec is reasonable)

I have a recently rolled Marlin from Build-me-Marlin (built today).

I'm using Printrun, and 250000 baud.

Then all of a sudden, in the middle of the print, it started jerking while doing the profiles, but still going nice and fast on the infill. I thought maybe it was because I closed Firefox on the PC. So I stopped the print, restarted the computer, unplugged the USB cable to the Ultimaker, unplugged the power to the Ultimaker. I let it cool for about 1/2 hour, then powered the computer back on, powered the Ultimaker back on, plugged the USB cable back in, started Printrun again, loaded up the exact same gcode file and started printing again from scratch (after removing the partial print from the table).

But it is still jerking on the profiles, starting on layer 2 (layer one prints at 30% of top speed and prints just fine). Remember, I was able to print 10mm before - about 125 layers.

I thought it may have been the steppers or stepper drivers overheating, thus I let it cool for 1/2 hour. I thought something on Windows 7 might have been interfering with the USB->Serial port driver etc, thus the complete restart. I also reflashed the firmware, just in case. Nothing has helped.

It still seems to follow the correct path - I don't think steps are being missed - its just coming out blobby because of all the pauses, but other than that, all seems well.

Any ideas what may be going wrong? I'm at a loss of even how to diagnose it - are there any diagnostic M-codes that will tell me things like if the stepper drivers have been overheating or anything like that? Is it possible that although the USB->Serial interface is connecting at 250000 baud, it has been secretly slowed down by Windows7?

  • Link to post
    Share on other sites

    Posted · Suddenly staggering after initially smooth high speed printi

    Since it's so consistent I doubt this will work but it's worth a shot. Try giving Printrun a higher priority by opening the Task Manager (ctrl+alt+delete), go to the processes tab, find printrun, right click and choose "Higher than normal" under "Set priority" (roughly translated from Swedish but it should be fairly close). What this does is to make Windows assign more of the processors time to Printrun so that other programs asking for CPU cycles will have to wait their turn.

  • Link to post
    Share on other sites

    Posted · Suddenly staggering after initially smooth high speed printi

    Well I'm more confused than ever, but I got to print Yoda at around F15000 - I just don't know what happened.

    I thought I'd try slowing it down a bit, so I opened the gcode file in an editor an replaced F15000 with F10000 (not realising that only the first few layers used that exact feedrate). I saved, opened Printrun, and printed perfectly.

    But halfway through the print I thought to myself "it seems really fast". So I looked at the gcode file and realised that from about layer 5 it was printing at F16283 or something, and the feedrates were constantly changing - obviously a setting in Slic3r I don't understand. Nevertheless, it was printing smoothly at the feedrates that were causing me problems before.

    If the staggering occurs again, I will try assigning Printrun a higher priority in Windows, and will see if that's the source of the problem.

    Thanks for the help.

  • Link to post
    Share on other sites

    Posted · Suddenly staggering after initially smooth high speed printi

    it is easy to explain the non-staggering infill: straight lines take longer to print, so there needs to go much less info over the line. That means no buffer underruns and no slowdown or stopping. That is most likely what is happening to your perimeters, if your STL was very detailed, the resulting gcode to the perimeter will have a lot of very small segments that take more time to send than to execute. Marlin tries to mitigate this by going slower when its buffer gets low, but when conditions are marginal it will stop once in a while.

    See if reducing the baudrate to 115200 makes the problem go away. Another option is to decimate the stl in meshlab (reduce the number of facets) to make the average path lenght longer.

  • Link to post
    Share on other sites

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now
    • Our picks

      • UltiMaker Cura 5.9 stable released!
        Here comes Cura 5.9 and in this stable release we have lots of material and printer profiles for UltiMaker printers, including the newly released Sketch Sprint. Additionally, scarf seams have been introduced alongside even more print settings and improvements.  Check out the rest of this article to find out the details on all of that and more
          • Like
        • 5 replies
      • Introducing the UltiMaker Factor 4
        We are happy to announce the next evolution in the UltiMaker 3D printer lineup: the UltiMaker Factor 4 industrial-grade 3D printer, designed to take manufacturing to new levels of efficiency and reliability. Factor 4 is an end-to-end 3D printing solution for light industrial applications
          • Heart
          • Thanks
          • Like
        • 7 replies
    ×
    ×
    • Create New...