Separate Prime and Suck Speeds

[mhackney]

Many rapid suck/prime moves in quick succession can often lead to jams - especially with PLA that seems to exhibit more thixotropic behavior. Ideally, you'd like to have a fast suck to "snap" the filament into the nozzle to minimize/prevent oozing and a slow prime move to not "micro jam" in the hotend. I've spent an inordinate amount of time studying this behavior. I can 100% reproduce this hot end jamming problem on a specific part I have printed in PLA with 40mm/s prime/suck speed. I have written a script to process the gcode to change the prime to 20mm/s (leaving the retract at 40mm/s) and the problem completely goes away. Sneak the prime speed up and at around 30 mm/s the jamming problem starts to pop up again.

regards,
Michael

[Garry Bartsch]

This is intriguing.

How close together must the prime/suck operations be to induce the jamming? Sometimes prints I make seem to have a lot of prime/suck operations in what seems to be close succession but I've never had a jam due to that. But my idea of "close succession" may not be similar to what you mean by close. Also I use a J-head which seems to play nicely with PLA because of the Teflon tubing. It seems metal hotend uses have reported jamming issues printing PLA more often.

[lonesock]

OK, it's on my ToDo list.

Jonathan

[mhackney]

Thanks Jonathan.

Garry, there are a lot of factors involved and I've observed that not all of them are required to produce the problem. Even with a J-Head I can produce the effect (I call it hydraulic jamming). The nozzle bore length to diameter ratio also has a big effect. This was a big issue with the V4 and previous E3D hot ends (easily fixed) but not the latest. Other hot ends also have a large L:D ratio. The J-Heads I have were all much better (ratios <2). Extrusion temperatures have a great effect too, the hotter the temp, the more frequent the problem. This plays right into the assumption many users make that "hotter is better" and print PLA at higher than needed temperature.

I actually haven't tried a delay between a fast retract and a fast prime, that might be an interesting experiment,

cheers,
Michael

[Dreide]

I guess that different extruders and different feed systems (direct vs. bowden) show very different behavior. Although I don' have any problems with extruder clogging, I think there is room for improvement regarding the destring procedure.
I would like to suggest adding two more parameters, namely secondary retraction and prime speeds. The idea is the following: You first do a relatively fast but small retraction, just enough to release the pressure in the nozzle. After that you keep retracting very slowly until the end of the travel (including the wipe, i.e., until priming). The priming is then relatively fast (same speed as retraction would be fine with me) but not all material that was retracted will be primed (so as to avoid blobs). The remaining material will be "primed" during the following print (meaning a temporal increase of flow rate) until the material account is balanced (i.e., accumulated retraction length = total prime length).
My guess is that retracting slowly and dependent on the travel distance would improve the oozing situation and also allow priming with fewer problems. Secondary priming would take care of the problem of underextrusion that we have right now when using prime<suck, especially when having a lot of destring events in rapid succession. Regarding the parametrization, I am not sure whether it would be necessary to explicitly set a limit for retraction length, but I don't think so. I am also not quite sure if the priming parameters should be somehow scaled with respect to the actual retraction length. At least the priming distance parameter would have to be redefined anyway in order to be compatible with variable extraction lengths.
Obviously, this is a bit more complicated to implement than just adding a separate priming speed parameter, although it is just a manipulation of the E values. Moreover, this feature would require quite some fiddling on the user's side, so no KISS here. But the potential benefits might be worth it. Any thoughts?

EDIT: ??? According to this post http://www.cubexupgrade.com/tipstricks/ ... primesuck/, apparently something similar has been implemented in some intermediate (?) version of KISSlicer. Can somebody shed light on this, that is, why it has disappeared in the current version? Has it?

[Hugues]

hi Driede,

What you read on cubexupgrade about "dynamic" prime&suck is specific to the cubex firmware. Giovanni who design cubeitmod (postprocessor for cubex) change some kisslicer box to match the information. It's not easy to setup because you've to find the good balance between long and short travels !

[Dreide]

Hugues, thanks for the info.

[lonesock]

OK, there is a new Windows build for you to try with distinct suck and prime speeds.

As for a more complex / complete solution, I agree that we need it, but hopefully this works for now. I _really_ want to get the 1.5 release polished and out the door.

thanks,
Jonathan

[mhackney]

Fantastic thanks Jonathan. I'll grab it now.

cheers,
Michael

[mhackney]

I declare this implementation a success! I am now able to automatically generate gcode and not have to post process it to get fast suck (50mm/s), slow prime (20mm/s) and getting no blobbing or other artifacts with PLA. AND, the dreaded "hydraulic plugging" phenomenon that I attest to the thixotropic behavior of PLA is not there. My torture test part will "plug" most hot ends or poor gcode unless suck/prime is very slow. Now I can print these faster and reliable.