Stuttering on certain geometry while printing from USB - Taz5 Archim2 Aero build

[hrabbot]

Printing from Octoprint on Raspberry Pi 4B - baud rate 250k. Certain prints are unable to stream adequately for printing, and cause stuttering and associated poor print quality. Reducing print speed (feedrate) manually on Taz LCD remedies the stuttering. ( around 40% of full speed) Most observed when printing thin walled, single extrusion width curves. Example gcode of a single extrusion width cylindrical object attached. This toolpath has been run on other printers without stuttering.

Comparison images also attached.

Stuttering Example.gcode.txt

[marciot]

@hrabbot: I'm sorry for the delay in getting back to you on this. On the Archim, the MIN_STEPS_PER_SEGMENT was decreased to 1 from 6 under the assumption that the board could keep up. It is possible this assumption was incorrect. Can you try the following firmware and let me know if the issue is resolved?

Marlin_TAZ5Archim_Aerostruder_2.0.0.1_MIN_STEPS_6.bin.zip

The former build sets it to the value of six as used on the Rambo. Here is another build with MIN_STEPS_PER_SEGMENT set half way, at three:

Marlin_TAZ5Archim_Aerostruder_2.0.0.1_MIN_STEPS_3.bin.zip

If we find this helps, I can lower the raise the defaults for Archim board builds.

[hrabbot]

The MIN_STEPS_6 version did not affect output on this model. For this reason, I didn't test the MIN_STEPS_3 version. Printed from SD card. The model prints smoothly on CR-10 without stuttering, otherwise I have no other useful information at this time.

[marciot]

Interesting, and unfortunate. This may need to be reported in Marlin upstream as it really isn't something I can troubleshoot.

[SwiftNinja]

I'm out of my league on this one, given that it involves the planner, but I noticed a setting in the Configuration_adv.h file. Wonder if this is related to your issue? If your lookahead buffer is past half full, this would seem to tell the machine to cut the speed in half. ... But again, I'm out on a limb here.... and I can't offer much help here beyond this guess / query. In addition, it seems that "SLOWDOWN_DIVISOR" is a recent introduction to Marlin; I don't see the option in Lulzbots last 'unofficial' release which was 2.0.0.174 for the Bio.

// Slow down the machine if the lookahead buffer is (by default) half full. // Increase the slowdown divisor for larger buffer sizes.

define SLOWDOWN

if ENABLED(SLOWDOWN)

define SLOWDOWN_DIVISOR 2

endif

This is referenced in src/module/planner.cpp

You could try commenting out #define SLOWDOWN and see if that makes a difference, but I don't know what bad things will befall your print if/when the planner lookahead buffer gets completely full. I notice your sample print is what looks to me to be a high-poly count circle. Maybe you've got other options turned on in the firmware that is creating a significant number of step movements to accommodate that, like S_CURVE_ACCELERATION, or something like that? EG, there may be other options you have enabled which are causing the planner buffer to get to that failure point.

Maybe it helps, maybe not, but good luck either way with your issue!