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?
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.
Purple = sarcasm
Please do a board search before posting your question, many have been answered with very time consuming detail already.
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.
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%.
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?
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.
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.
"Now you see why evil will always triumph! Because good is dumb." - Spaceballs
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
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.
"Give a man a compliment and he'll be all, 'Yeah, I've been working out.' Teach a man to fish for a compliment and he'll be all, 'I feel SO fat.'" - Bob FM
