Doesnt Calculate Thin Walls

[plexus]

wow. that is a serious flaw. i just tried it and had to mess with oversampling to get a solid loop.

feature request: a check box for "make printable" which will automatically adjust parameters to ensure the output is printable. actually how about just building this in as I can't think of a use case for gcode that can't be printed.

also just to clarify: after experiencing this flaw with KISS, i d/led Slic3r. i havent used it in so long I forgot how it worked. I loaded the box and was looking around for a slice button. after I remembered that it just doesn't it once the model is loaded, it had sliced it in 7 seconds with paths that would print. same print params as KISS. to get KISS to slice it with no paths takes 65 seconds, almost 10x. so it's not true that the other slicers take as long as KISS to create a printable file.

Look, I have no religious alignment to anything. these are just tools to me. so if "the hammer" has a flaw it has a flaw and should be called out. its the only way to make the tools better. KISS is a great slicer from all other features. I have very little critical to say about anything else. the user interface and usability is now my #2 critical issue (its was #1 of a list that was 1 long). now the list is 2 long: #1: creating printable files with physical parameters that make sense in a reasonable amount of time (equal or faster than other slicers) and #2 is the UI and usability.

I can't help with #1 other than beta testing but I can help with #2 as I am a User Experience Designer with 20 years experience creating software interfaces and have offered to design the UI for KISS. keep it in mind. (but I may have to use Slic3r if KISS wont create a printable file, in the meantime to satisfy client needs and keep things in budget. and now I can't rely on KISS I will have to thoroughly check the visualized gcode... ugh)

[PenskeGuy]

In testing this, I liked how v1.4 worked. It didn't try to cram paths into where they obviously won't fit. Tells you right off that there's not enough space by either producing a Crowning path or, in the case of serious model deficiency, no path at all. So, in that light, it would appear that v1.5 has slipped into an area that it needs to retract from just a bit. As I said earlier, two objects cannot occupy the same space at the same time; and the current KS is attempting to cram three of them in there. This could lead to issues in other areas; not just modeled thin walls, which is something of a special case.

A case in point: Rounded corners have been the most cited situation where people complain. Obtaining true uniform wall thickness when modeling is crucial. Concentricity around corners that blend from straight sections isn't always easy. Depending upon the modeler you choose, it may be near to impossible. If you can't do that, or don't know how to accurately fix it if it happens, then you should find another method to get to where you want to go.

It's a double-edged sword. You like how KS does just about everything. Yet, there's this one little thing..... Well, sometimes, you can't have everything. Concessions must be made in one or two areas if the application is going to excel in most. Accommodating this may dull the sharpness of many.

For me, as opposed to rewriting the code in a quite probable significant amount, dropping the Extrusion Width for a problem model is really small potatoes. Then again, I don't even try to do something that I surmise won't work when creating the model in the first place. It's an overall approach. Doing something unawares and then getting to the end step; relying upon something to "save the day", just isn't in my wheelhouse. In the case of the supplied box STL, creating that shape as a solid and choosing Vase mode with the desired Skin Thickness would reliably print that file in a heartbeat. Simple.

[plexus]

Its not simple as I am using KISS primarily for business. clients supply the STLs and its a lot more work and impossible to be competitive if I have to fiddle with parameters to get printable code. In my mind a key point of a slicer should do the smartest things to produce printable code. otherwise what are we going to use the code for? wallpaper?

fail

Jonathan, any chance of addressing these issues. Id rather wait for a rewrite and have this fixed. its a deal breaker.

[PenskeGuy]

Hey, we get crap from clients all the time. What with the "easy" tools out there to use such that any bozo can produce a model that "looks" like it will work, but can't, it comes with the territory that we have to either budget time to fix it, and charge the client for same because they provided a Borked model, or inform them that said model is unusable and let then know where the problem areas are so they can do better this and in future times. Sometimes, if the client is valuable and has a clue, we do the fixing while informing and not charging. Good business. Still walls that are too thin are walls that are too thin. Sure, Slic3r and [insert other application here] will slice the file but what do you actually get when it is printed? Dimensionally accurate? I'm guessing no.

It's a mindset and I guess we're always going to disagree on this type of stuff.

[plexus]

I will test and report back.

[lonesock]

Hey, everybody!

I am looking into this. It *is* a issue, and I want KISSlicer to be able to handle these cases. Note that if the STL is bad, and I can't physically print a wall as thin as requested, I should flag the problem. However, I am guessing most people would rather have a feature exist and be a bit thicker, than not exist at all.

One thing I do want to say is that "crowning" is the function that is supposed to handle these problems. A loop has to be inset from the surface by 1/2 the extrusion width, and there are many cases (as I'm sure you have discovered / known) where either a loop will not fit, or 2 loops get crammed in together and are too close to each other. Crowning is supposed to detect those cases and replace the offending (or missing) loop(s) with a single crowning path.

If you disable crowning (or make the crowning threshold too long) you cripple the mechanism for fixing the problem. I almost always run my crowning threshold at 0. I also default my oversample resolution to 0.125 [mm], but I do crank that down from time to time to catch extra-sharp edges, or extra-thin walls.

thanks,
Jonathan

[plexus]

Hey, everybody! I am looking into this. It *is* a issue, and I want KISSlicer to be able to handle these cases.

Thanks lonesock! Recently a client asked me to print this popular hairclip as part of an order http://www.thingiverse.com/thing:9948

The zigzag "spring" would not slice in a way that was printable. this confused me because I know I've sliced it fine with an older version of KS. but with 1.5 beta, I could not get the zigzag solid. I didn't even think to adjust the over-sampling parameter as I don't really know what it does and its not a parameter I would attribute to the problem. the only parameter that helped was reducing the nozzle size down to 0.2mm and even then it wasn't perfect. this required me to do a nozzle change-out which is time consuming and has some risk associated to it. since I print commercially for clients this wall issue is a huge concern for me.

So that is the kind of model and issue this is about. it would be great to have KS focused on producing printable gcode and if it can't throw a very clear error as to why and, if usability is a priority, also give suggestions on what to change to make it work.