Stuttering Marlin

[c-ernst 1]

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

[Daid 306]

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.

[c-ernst 1]

I set it to 250000 before and repg couldn't connect to it. That was the cruddy version of Marlin though.

I will gives your suggestions a try.

Thanks!

Chuck

[Daid 306]

You'll need to modify RepG before it connects to 250000, but using PrintRun is better overall.

[tom 0]

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.

[owen 19]

With Printrun is it possible to edit your GCode from the program like you can with RepG?

[Daid 306]

Nope, but any basic text editor can edit GCode. Not sure why you want to edit it...

[ddurant 0]

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.

[c-ernst 1]

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

[c-ernst 1]

How do you modify rep g to talk at 250?

[owen 19]

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.

[owen 19]

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.

[c-ernst 1]

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

[Daid 306]

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)

[owen 19]

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.

[c-ernst 1]

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

[Daid 306]

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)

[owen 19]

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

[Mattyk 1]

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!

[gr5 2,294]

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.