Jump to content
Ultimaker Community of 3D Printing Experts
Sign in to follow this  
gavinmetzler

Suddenly staggering after initially smooth high speed printi

Recommended Posts

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


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
Sign in to follow this  

  • Our picks

    • Taking Advantage of DfAM
      This is a statement that’s often made about AM/3DP. I'll focus on the way DfAM can take advantage of some of the unique capabilities that AM and 3DP have to offer. I personally think that the use of AM/3DP for light-weighting is one of it’s most exciting possibilities and one that could play a key part in the sustainability of design and manufacturing in the future.
        • Like
      • 3 replies
×

Important Information

Welcome to the Ultimaker Community of 3D printing experts. Visit the following links to read more about our Terms of Use or our Privacy Policy. Thank you!