Jump to content
Ultimaker Community of 3D Printing Experts
c-ernst

Stuttering Marlin

Recommended Posts

Marlin updated firmware still stutters on complex moves. A simple circle will sometimes end up with super tiny pauses that make small blobs. The machine is running spectacular and I can do head moves in the 200+ range no problem. The motors definitely sound like it's choking in the communications area.

Even when I dial back the feeds to 50 or so, large complex moves stutter.

WIll PrintRun solve this issue? Is there anything else I should be looking for?

I am using this version of Marlin

http://forum.ultimaker.com/download/file.php?id=49

Supplied by Dave Durant... (thanks Dave!) it was the only version that I could get to work.

I am currently using Vista 64.

Chuck

Share this post


Link to post
Share on other sites

You could increase the baudrate to 250000, this could help. Also, using PrintRun will really help.

And as a last resort you could open the GCode file, and replace all the spaces with nothing. This will make GCode that most tools won't understand, but the Marlin firmware will understand it. It saves about 10% of communication data.

Share this post


Link to post
Share on other sites

I have to agree with Daid here. I ended up trying printrun because I was having issues connecting RepG to the latest marlin firmware. But that was a happy decision. I greatly prefer printrun after having used it for a couple of prints.

Share this post


Link to post
Share on other sites

I think there's a Marlin bug here.. I also notIce a small stutter, even at low speed.

Definitely not because of the baud rate being too low - I've printed far faster at the same rate with earlier versions.

Share this post


Link to post
Share on other sites

I just conducted a bunch of tests. It has nothing to do with the print speed. I just cut the speed to .25 of what I was printing before. It just stutters randomly and only on complex head moves. You could print boxes at 150mm all day with no problems.

Anyone know how to report marlin bugs and to whom?

Chuck

Share this post


Link to post
Share on other sites
Nope, but any basic text editor can edit GCode. Not sure why you want to edit it...

I like to home the nozzle, then set the temp and wait, which I set as start code through Netfabb. G28 followed by M109 S210

I like to edit out the M109 command set by Netfab when the Nozzle is raised above the platform and the M109 S0 at the end which causes the nozzle not to home or turn off the heater at completion of the print.

I have Netfab put in a M104 SO at the end.

Hope that all makes sense.

Share this post


Link to post
Share on other sites

I couldn't get RepG or printrun to go at 250,000 on my Win7 32Bit Laptop that I print from. From memory RepG just didn't work at all and printrun sent bytes at the speed but they appeared partly garbled.

Share this post


Link to post
Share on other sites

Used Pronterface ( https://github.com/kliment/Printrun) and it eliminated almost all the hiccups. I still get them every once and a while but so far it helped a lot.

Been printing at 150mm and it's pretty smooth. One thing I am noticing is the firmware's "smoothing" of the meshes makes for sometimes inaccurate surfaces. I will print a perfect sphere and it will end up with odd shapes in it. Basically anything with a long mathematically perfect curve will get "re-interpreted". I expect this from an algorithm smoothing out a course mesh but I am feeding the machine pretty dense meshes. Is there anywhere in the firmware to dial this back or turn it off for problematic prints?

Chuck

Share this post


Link to post
Share on other sites
Used Pronterface ( https://github.com/kliment/Printrun) and it eliminated almost all the hiccups. I still get them every once and a while but so far it helped a lot.

Been printing at 150mm and it's pretty smooth. One thing I am noticing is the firmware's "smoothing" of the meshes makes for sometimes inaccurate surfaces. I will print a perfect sphere and it will end up with odd shapes in it. Basically anything with a long mathematically perfect curve will get "re-interpreted". I expect this from an algorithm smoothing out a course mesh but I am feeding the machine pretty dense meshes. Is there anywhere in the firmware to dial this back or turn it off for problematic prints?

Chuck

I think you have a problem with belt tension. This also causes circles to go square a bit. The marlin algorithm doesn't change the actual line it prints, it only changes the speed at which it does (acceleration to prevent jerky movements)

Share this post


Link to post
Share on other sites
The marlin algorithm doesn't change the actual line it prints, it only changes the speed at which it does (acceleration to prevent jerky movements)

Actually I think I read it does actually sees if there is an arc and smooths it out.

Share this post


Link to post
Share on other sites

The belts are pretty tight, I printed out some belt tighteners.

I read the marlin info and it does talk about some arc calculation algorithms. I did an experiment where I printed a sphere, (85000 poly) then printed it slightly larger and one small (2%) and compared what the thing was coming up with. The larger and smaller printed fine. The original printed with a slightly flat side. I also printer super small spheres (1/4") and got the same thing. It's like there is some mathematical sweet spot on firmware that does this.

Really odd.

Chuck

Share this post


Link to post
Share on other sites
The marlin algorithm doesn't change the actual line it prints, it only changes the speed at which it does (acceleration to prevent jerky movements)

Actually I think I read it does actually sees if there is an arc and smooths it out.

Actually, Slic3r can do that. And emits a G2 or G3 code then. Which the Marlin firmware understands as an arc. But Marlin itself does no attempt in trying to find arcs itself (it doesn't have the time to do so)

Share this post


Link to post
Share on other sites
The marlin algorithm doesn't change the actual line it prints, it only changes the speed at which it does (acceleration to prevent jerky movements)

Actually I think I read it does actually sees if there is an arc and smooths it out.

Actually, Slic3r can do that. And emits a G2 or G3 code then. Which the Marlin firmware understands as an arc. But Marlin itself does no attempt in trying to find arcs itself (it doesn't have the time to do so)

OK Thanks

Share this post


Link to post
Share on other sites

I signed up just to reply to this ancient topic. because it mirrored my hardware/software setup and i had the same issues. But i had a shred of luck and all my problems where solved and wanted to help others in my predicament... get a powerful computer to run the software or at very least... turn off the extruder travel real-time monitor. This process of reading the g-code and drawing it on screen and sending it to the printer caused a MASSIVE memory leak and ment steps were being skipped towards the printer, causing the choking. I click on g-code or any other view in that pane and instantly my printer takes 3 viagras and runs silky smooth and fast!

  • Like 1

Share this post


Link to post
Share on other sites

Well that's if you print through Cura I suppose. If you print from an SD card and you get stuttering then there are simply too many points too close together. Marlin has to be ready to stop 16 points ahead and if you have say 80 points in the space of say 2mm then you are going to have serious stuttering.

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

×

Important Information

Terms of Use Privacy Policy