kisslicertalk.com

..My concern is not about ringing (at all - its 100% controlable by speed/acc, as You mentioned),
its about:
- some markings of loop start distributed on surface, when they should be located in corners
- these tiny diagonal artifact lines at the bottom corners of windows (first photo, I marked them with blue lines). They appear at places where pale magenta line meets cyan (on g-code preview in last attached photo). In 1.5 there were no such "effects".


....About aluminium, I'm succesful with prints (I guess) because it has rather low amount of metalic powder. It behaves just like plain PLA. I'ts some Chinese no-name type.

This is the "seam" on the back of a Nefertiti bust:
I also printed the same model in Copperfill with identical results. However, I printed at layer height of 75 microns. At 0.2mm layers, the seam was slightly more pronounced.

Peter

Hello,

I'm willing to print Banzai Bill, but I have issues when I try to slice the pupils. There are some errors in the STL, but even after a repair, the slicing is far from perfect.
FYI, Simplify 3D slices it without any issue.

I'm really sure that is a bug, so I've attached both STL and my project files.
I'm using the 1.6 RC2.5.

ViscoElasticity|Experimental calculator computes VE value exactly 4 times smaller than what I get from the standard laminar flow in pipe formula (e.g. hyperphysics.phy-astr.gsu.edu/hbase/pfric.html). Maybe a typo in the code?

Heh, you are exactly correct about the math, and the factor of 4. That is intentional, though, as running a bunch of materials through experimental wizard, then through the tuning wizard, then fine tuning while printing showed approximately that reduction, and /4 was the closest nice integer. So it started life off as good science, then had an experimental factor thrown in. [8^)

Jonathan

I am using the Mac version. In version 1.6, the language file "kisslicer_langage.pot" can not be generated.

K.Miya wrote:I am using the Mac version. In version 1.6, the language file "kisslicer_langage.pot" can not be generated.

Got it, thanks.

Jonathan

lonesock wrote:Heh, you are exactly correct about the math, and the factor of 4. That is intentional, though, as running a bunch of materials through experimental wizard, then through the tuning wizard, then fine tuning while printing showed approximately that reduction, and /4 was the closest nice integer. So it started life off as good science, then had an experimental factor thrown in. [8^)

Umm... that disturbs me a little. Kisslicer relies on a single-parameter linear model of the extrusion drivetrain. As best I can tell, It chooses a smooth drive profile bounded by +/-preload_speed, uses the model to deduce the actual material flow, and matches head travel speed to that flow. Yet when the simplest drive profile -- an abrupt stop -- is plugged into that same model, the results are off by a factor of 4. Makes one wonder how well the model performs at other times. When the print is an engineering component rather than a figurine, especially with fine detail and thin walls, strings and seams are not the only things that matter.

Beefeater wrote:

lonesock wrote:Heh, you are exactly correct about the math, and the factor of 4. That is intentional, though, as running a bunch of materials through experimental wizard, then through the tuning wizard, then fine tuning while printing showed approximately that reduction, and /4 was the closest nice integer. So it started life off as good science, then had an experimental factor thrown in. [8^)

Umm... that disturbs me a little. Kisslicer relies on a single-parameter linear model of the extrusion drivetrain. As best I can tell, It chooses a smooth drive profile bounded by +/-preload_speed, uses the model to deduce the actual material flow, and matches head travel speed to that flow. Yet when the simplest drive profile -- an abrupt stop -- is plugged into that same model, the results are off by a factor of 4. Makes one wonder how well the model performs at other times. When the print is an engineering component rather than a figurine, especially with fine detail and thin walls, strings and seams are not the only things that matter.

KISSlicer started out with Preload calculation implemented as a simple scaling factor * the flow-rate. That was just to get the magnitude of extra filament to be driven at full flow, not to control the actual flow rate or head speed itself. The actual feeds and speeds profiles are generated based on that Preload magnitude and the preload speed, as you surmised.

Before releasing KISSlicer into the wild, though, I needed a way to compensate for different extruder configurations, otherwise it would be impossible to have a good starting point for sharing material Profiles. So I started splitting the Preload function into the material's component PreloadVE, and the extruder's components. That is when I looked at the Hagen–Poiseuille equation, and verified that I could get decent prints with the same material PreloadVE value modulated as expected by the extruder dimensions.

I feel that the fact that KISSlicer uses the same exact model, but with a linear scaling factor, has more to do with the fact that the internal feeds and speeds profiles was arbitrarily scaled initially. When choosing to name PreloadVE and pick units, I just stuck with the physical units, though I guess technically it should be called [microseconds/4]. Also note that the linear model is inadequate. You can't use it over extremely large flow rate ranges, especially with softer materials. It also doesn't account for things like stiction in the tube when the material is slowly driven. However, I was thinking it would be hard enough to get users to tune a single new parameter ("Other slicers don't make me do that!" [8^), nevermind trying to figure out a decent experimental test to generate a higher order approximation!

thanks,
Jonathan

I'm running a few tests right now and may have some ideas for you. Stay tuned.

Boris