kisslicertalk.com

funBart wrote:

2017-07-08_21-04-23.jpg

KISSlicer isn't getting typical overhangs yet .

I mean overhangs that are 'dripping" Or Ice Pillars. Or Stalactites
Like these:

2017-07-08_21-05-40.jpg

It's resulting in insufficient support structure:

2017-07-08_21-04-23.jpg

Reducing the oversample resolution didn't help.

The test stl is here. https://www.thingiverse.com/thing:635497/#files

Look at all the shape of your part in all direction (X and Y), you will see that shape angle are too small for being supported without a lower support angle setting (zero).

Look at all the shape of your part in all direction (X and Y), you will see that shape angle are too small for being supported without a lower support angle setting (zero).[/quote]

Can be, can be! But in real live it needs a support structure.

I don't know how other slicers get it done, but of the 6 slicers I tested there were 3 that were able to recognize that extreme overhang and generate support.
Test spreadsheet here:
https://www.craftbot.nl/2017/04/04/new- ... comparing/

That is a great support test. I guess I just never considered printing sharp edges down. I can't think of an easy way to get it into the 1.6 release, but it's now on the list for 2.0.

thanks,
Jonathan

lonesock wrote:That is a great support test. I guess I just never considered printing sharp edges down. I can't think of an easy way to get it into the 1.6 release, but it's now on the list for 2.0.

thanks,
Jonathan

That model is made by the great Sandor (Psanyi) that implemented the Advance feature in the CraftBot firmware. It's here on thingiverse. It's actually two overhang tests, one with a sharp edge, and one with a camfer. See here:
https://www.thingiverse.com/thing:635497

For me the new Advance feature is a bridge to far. And I like extreme difficult settings in slicers! To understand them makes me think I'm a great person.
I would suggest to introduce an extra settings level after Expert: Autistic Level.

Anyway, first tests with the advance feature, or preload seemed not to have any influence on the generated Gcode. We probably miss some setting or insight:

Sandor:

Interesting. I've tried it, but it does nothing for me. If I set the
PreloadVE parameter to 100 and 1000 the only difference is this comment
in the gcode:

; matl_viscosity_over_elasticity_us = 100
vs
; matl_viscosity_over_elasticity_us = 1000

The "preload_factor" is 0 always and the file is full of comments
containing "preload 0.000000". I guess I'm missing something.

Regards,

Sandor

I am actually installing software to do some short "screen capture + voice over" videos, specifically to cover the new settings / features / "what was Jonathan thinking?!?" moments.

But I'll do a quick text-version justification of "why Preload", starting in lame story mode.

In the beginning was the extruder. It turned, and plastic came out (sometimes), and people thought that it was good.

Then, it was noticed that enough plastic wasn't coming out at the beginning, and too much plastic was coming out at the end of paths, and there sprang forth destring. And people thought that it was good.

And lo, it was observed that you would get a blob at the start of paths, and one at the end, while destring was happening. Thus came asymmetrical prime and retract values and speeds, and even the 'coast' function, and variable loop gaps, and attempts to adapt destring speeds to the path speed...etc. And people thought that it was...OK, at least as long as you didn't change your head speeds or layer thicknesses too much.

The thing is, if you drive some volume of plastic via your extruder, that plastic does not instantaneously come out of the nozzle. The flow coming out of the nozzle will speed up, finally getting to steady state (where the plastic pushed in by the extruder equals the plastic coming out of the nozzle), then when you stop the extruder it continues to ooze out, with the flow rate falling off until finally it is done. What I really really really wanted was for KISSlicer to handle all of that for me!

I did some modeling on this, and came up with an internal mathematical model of how this all functions, so KISSlicer can predict how much material is coming out of the nozzle at any given time. Given this model, KISSlicer can (and now does) drive the extruder, numerically model how much plastic is actually coming out of the nozzle, and vary the head speed to precisely match the plastic deposited. Of course, there has to be some number that controls how the flow out relates to the flow in (with some extra state variables that only KISSlicer needs to keep track of). The good news is that it boils down to one single number. The bad news is that it is dependent on both the extruder dimensions, and the material properties.

In the first version of Preload there was only 1 new parameter, a single preload value that was stored with the material profile. But it varied wildly depending on the printer in use, and it was impossible to use the same material profile on different printers, or different extruders with differing nozzle sizes on the same printer, let alone share material profiles with someone, even to get a decent starting point! So I had to split it into at least 1 number for the extruder configuration, and one number for the material properties.

The extruder properties that contribute to the equation are now found in the [Printer]->[Extruder Hardware] tab, and they are the nozzle diameter, nozzle length, and drive length. I could have combined them all into a single number, but the number would have been meaningless, and hard to measure, so I left them as 3 constituent parts. The nozzle diameter is known, the drive length is easy to measure, and the nozzle length can be looked up or estimated easily. I also have plans to use the nozzle diameter in the style settings later, so I really wanted that value distinct anyway. Note: you need all three of these values to be non-0 (and hopefully close to the real dimensions!) before preload can function.

The material properties are much harder to look up, which is why I did not release KISSlicer 1.6 beta until I had the Tuning Wizard and the PreloadVE experimental Wizard thing. Those tools make it relatively painless to get a decent preloadVE number for the material, *ONCE I FINALLY DOCUMENT WHAT YOU ARE SUPPOSED TO DO!!* That will be the subject of one of the first of those videos I mentioned. The short version is that I run the experimental version first, get a starting value, then run the Tuning Wizard with a specific model and style profile to find a nice value. That's it, about 30 minutes of print time per material that I need to characterize.

Once the preload is tuned well, suddenly the destring works well with smaller values, and can be driven faster (since there is really no load left on the filament). It also adapts to whatever flow rate you happen to be using, so it works well for fast or slow paths and thick or thin layers. No more tuning your destring parameters to look OK for perimeters, but not so great on solid surfaces (or vice versa).

OK, well, this post has gone on waaaaay too long, sorry about that. I'll get back to programming now, but hopefully you won't just ignore Preload completely. Yes, it is a complex concept. Yes it is extra work tuning your material profile. Yes it is one more thing that KISSlicer does differently for other slicers. But Preload is not just something I threw in to be different. I believe it closely follows how the system is actually working, and it can give great results.

thanks for your time,
Jonathan

Thanks for clarification!
I now feel the need, desire, obligation and drive to try the Tuning Wizard to get a start with the Preload function

In the beginning was the extruder. It turned, and plastic came out (sometimes), and people thought that it was good.

As I started 3D printing years ago (the dollars were made of wood, and the goats still could fly) when there was no acceleration available yet, is it so that not-accelerated printing hadn't that problem? As all XY and E values had always the same relative values to each other? And by that there was no slowing down each line segment and by that no delayed response of the extrusion?

If so, than I would think:
-In the beginning was the extruder. It turned, and plastic came out, and prints were beautiful, so people thought that it was good.
-But the Devil seeded displeasure in the minds of the Coding Nerds, not to be satisfied, as printing was slow.
-As God was on vacation when mankind was poisoned by the Devil to believe that "time was money" , the Coding Nerds were forced to implement acceleration algorithms to speed things up. So now prints are finished in 5 hours in stead of 10.
-And people were displeased as their prints were ugly. They forced the Coding Nerds again -and without mercy- to solve that.
-The Coding Nerds did what the could, but reality was so complex that it resulted in an even more complex solution.
-So now the People had to be like a God, to understand reality and settings to get a result they forgot to be possible when just taking time.

Is it so that velocity printing is solving the problem too? I mean that by a steady extruder pressure, so velocity driven, the advance / Preload isn't needed?
It's discussed at the Machinekit forum for example.
https://groups.google.com/forum/?fromgr ... w6pPBV9XsJ

pjr wrote: Prime Pillar is affected by the brim option, and the raft under the brim of the pillar do not "match" (Olivier13)
There are two Prime Pillars (Olivier13)
(pjr)

Hi pjr
I'm on 1.6beta1.5
Please, can you remove this two lines? Brim on pillar is a good idea
And about the two pillars, I mean "double"...
so, you could add this one in features :
Pillar options : allow user to choose if Single or Double pillar per extruder
Thanks a lot.

Olivier13 wrote: Please, can you remove this two lines? Brim on pillar is a good idea
And about the two pillars, I mean "double"...
so, you could add this one in features :
Pillar options : allow user to choose if Single or Double pillar per extruder
Thanks a lot.

Done.

Peter

*Under Material tab, destring for my materials was not correctly imported into the new version.

Hi. If you fill the list on the left with fully models, it stops displaying. We must rise to the beginning.