lonesock wrote:We'll get there (at least most of the way [8^). It's on the "ToDo for 1.6 Release" list. We may need to take this portion of the development into a different thread where I can more frequently update builds for just this issue. What OS are you running?
Win64. But it isn't as urgent as all that. Now that I've figured out the problem, I can turn off the overhang flow limit and wait for the regular 1.6 release. As long as it's in 1.6... Thank you, Jonathan!
About Preload. I experimented with ooze some months back. I am sure you've been more thorough than I have, but maybe my observations could still be helpful. I used a test pattern like in the attached picture. It has straight lines where extrusion stops in the middle of the line while travel continues, then starts again in the middle of the next line. This shows quantity and duration of ooze after extrusion stops, as well as quantity and duration of shortfall when extrusion restarts (which is ooze's twin brother and could cause problems also).
Intuitively, from a linear elastic model, one expects exponential decay with time constant determined by viscosity, Young modulus, channel geometry, etc., and total ooze amount proportional to flow rate prior to the stop. But what I saw was quite different:
(1) Slow ooze continues for a very long time ~15s.
(2) At low flow rates, amount of ooze is almost independent of original flow rate.
(3) At high flow rates, something like the expected exponential behavior seems to emerge, with ~1s time constant, adding to the slow ooze observed at low rates.
In my particular setup (Rapman 3.1 extruder / MakerBot 0.4mm nozzle / ABS at 240C) the "high" flow rates started at ~4mm^3/s. My absolute maximum flow rate is ~12cm^3/s, above which the drive mechanism begins to skip.
I conclude from this that traditional "wipe" and "coast" strategies are useless, since you can't out-wait the 15s slow ooze. (Disclaimer: Rapman extruders are of quite unusual design, this may not be true on other printers.) Destring works well, but should be tuned to the flow rate: specifically, "suck" tuned to the flow rate _prior_ to the jump, to relieve chamber pressure, and "prime" tuned to the flow rate _after_ the jump, to build up the necessary pressure. Which is just what BFB firmware allows you to do by inserting M227 before M101 for each path.
BFB still has two major limitations, though. First, strings always appear at high jump speeds because the pressure is not relieved quickly enough. Second, BFB has built-in speed ramp generation for travel speeds over 12mm/s. So if the command speed is, say, 40mm/s, there is over-deposition at both the start and the end of the path owing to gradual acceleration/deceleration. If the path segment is short (e.g. when tracing a curve), command speed is never reached and there's over-deposition everywhere. I suspect there are other printers out there that implement speed ramps, and Kisslicer's current Preload algorithm might not work well with any of them. Something to keep in mind.