Welcome to the SeeMeCNC Community

Hey anyone know how to stop this stuttering?

http://www.youtube.com/watch?v=eV571EH5euU

When it does this it BLOBS on the spot when it's slowing down.

Only seems to do it on more complicated parts i.e. will not do it on smooth walls, it's ruining alot of my prints.
Should I increase the baud rate from 250000? Use less of my 4 computer cores in the settings? A setting in Arduino possibly?

thank you in advance!

The video is private. Change the privacy setting on it and I'll take a look.

I haven't seen the video yet but, I think I know what your talking about. My MM will do it on really complicated stuff. I found that closing every other running program usually helps. It will also do it when I select to high of an infill with the honeycomb pattern.

sometimes the will printer stop and wait until the temperature is correct. For example, first layer 200c and next layer 190c.

OK changed from private so you can see it now.

I have 4 cores and usually nothing else running so I doubt it's a computer speed issue.

My temp is the same throughout and smooth perimeters print fine on prints that take even hours without stuttering.

I'd really love to get rid of it as I can't print most items without it looking bad.
thank you again!

mine does this also, i thought it was computer running programs in the background like virus scanners so i shut it off. it helped a little but it still doing it.

so maybe there's other programs running int he background i need to shut off.

i'm also running i7 processor.

Look at the printer's front panel. It shows the number of commands enqueued. If it ever hits zero, then your computer isn't keeping up. If it doesn't, then something else is wrong.

If it's not the computer, it could be the USB baud rate. Should be 250,000 bps.

There is an issue with the delta code in both repetier and marlin, it basically breaks down commanded moves into short linear segments, this code can starve the interrupt that does the actual motion.
Marlin is much worse than repetier. But both do it to some extent, the only time I really see it is on long slowi moves, but theoretically it can impact any move.

I can consistently reproduce this problem if I slow down the flow multiplier below 100% on the LCD panel while executing gcode with short moves on an SD card. It goes away when I turn the flow multiplier back up to 100%.

Thanks everyone for your insights!

Turns out Broose was right on! I turn the flow Multiply down to about 95 or 92 after the first 20 or so layers because I get too much flow ( even though I calibrated my extruder perfectly and a couple times to double check )

Tried the print partially again and left at 100, no stuttering, turned down to just 99, and it started stuttering again!.
Did it over and over to check and it was consistently good at 100%

Since I get to much buildup to the point where I get the nozzle touching previous layers and squashing a bit on higher prints I turn the flow down.

Should I lower the Flow % ( in Cura ) and the Extrusion Multiplier number in Slicer or would lowering the stepper motor number for the Extruder have the same effect?


thanks again!

so why it doing this now?? i've been printing for a month or two now with no issue and now its doing the stop and go motion.

ive turned down the feedrate and flow rate sliders many times, and it never did this. so what causes this to happen all the sudden.

Broose wrote:I can consistently reproduce this problem if I slow down the flow multiplier below 100% on the LCD panel while executing gcode with short moves on an SD card. It goes away when I turn the flow multiplier back up to 100%.

Yes I'd forgotten about this, it exacerbates the problem, I've never looked but I assume there must be an if around the multiply, and the multiply is enough for the delta code to starve.

The amount of starvation depends a lot on what you are printing.

I get stuttering if I drop the flow rate below 100. Interestingly, if I do the exact same thing in slicer (set flow multiplier but leave Repetier flowrate at 100%) it will not do so. The interrupt service routines are probably coded with such tight tolerances that the extra math required throws it off. I wonder if they're running at 20MHz or 16?

BTW, it doesn't matter if your data rate is 250000. I run it at 119200 all the time and my plan buffer never gets anywhere close to empty. I don't know why people think g-code needs a 250 kilobit link. That's enough for 320p video. You are never, ever, ever going to get close to that.

I noticed my max stuttering today and it was a result of my MAC not sending instructions to the MAX's queue. The MAC has power to spare so after some playing around I was able to duplicate the issue. When I am working on a very complex (meaning curvy) shape with honeycomb infill, I better set the repetier software to the objects position tab. Because if I leave it on the print panel tab the MAX will be stuttering and waiting on instructions in no time....... The weird thing is that it does not always happen and also I have noticed that since I switched to my MAC the estimated build times are WAAAAAAYYYY off. The software said 4 hours and the actual build took 7.5.

Yeah the Mac version of Repetier, seems to be off by a factor of 2 in build times.
You can starve the printer of data even at 250K if there are a lot of short moves, like hexagonal infill.
The issue with the link isn't really speed, it's latency between writes, the host writes 1 line at a time to the USB serial device, and waits for an ack, because of the way USB works, that greatly reduces the actual throughput.
250K has less jitter, so generally generates less errors than 115200, but in practice there isn't a huge difference.
The data starvation is the reason a lot of people will recommend printing from SD Card for best quality, the firmware actually slows the printer down as the queue drains, so you may not see it actually stop.

But this effect is orghogonal to the delta issue, which is worst on slow long moves.

Are there any pictures illustrating the same object printed at the two different port speeds?

What I do not fully understand with the stuttering issue is why it is magnified when going from the stock extruder to the ezstruder. I speculate it may have something to do with the number of steps per mm.

With the stock extruder, 584 steps per mm I could turn the feed rate down and not experience any stuttering unless I had the print rate cranked up to high speeds. With the ezstruder 92 steps per mm, as soon as my extrude rate is anything below 100% the stuttering makes the print unusable or halts the flow from the extruder entirely. Bumping it back to 100% or above returns everything to normal instantly.

I recently printed a gregs extruder which ups the steps per mm again and the stuttering much less likely to occur. Also allowing me to adjust my extrude rate below 100% without issues.

that's true flateric, that's the only difference in mine from previous prints, I'm running the so called ezstruder now

maybe its not so easy.

and maybe its time to changed back to a geared extruder but definitely not the seemecnc steves extruder.

I think the ez with a gearhead stepper would be unbeatable.

Flateric wrote:I think the ez with a gearhead stepper would be unbeatable.

Does anyone make a gearhead with the same bolt holes as a NEMA 17 motor?

the addon gearheads i found were way to pricey, might as well just buy another complete.

kbob wrote: Does anyone make a gearhead with the same bolt holes as a NEMA 17 motor?

Same bolt holes and 5mm shaft- then it would be a drop in replacement for ezstruder. With the 5.1 reduction gearmotor I have I need a both a NEMA 17 mounting flange and a drive roller bored to 8mm ID to adapt it to the ezstruder

Has anyone solved the studdering issue yet when using the new ezstruder? has anyone found a suitable geared extruder replacement?

What stuttering issue?

g.

I've only skimmed through the posts, so forgive me if this has already been said...

I've noticed this problem when using KISSlicer and having the resolution setting set to a very very high resolution. Now, this is only speculation, but I believe it has something to do with the command buffer size. If there are excessive move commands that are high resolution points of a very small area, the printer will execute that buffer extremely quickly and end up needing to wait for a new set of commands to be sent before it can continue moving. If this is indeed what is happening, then perhaps printing from an SD card may help (assuming it bypasses the buffer, which it may not), or by reducing the slicer resolution.