Beefeater wrote:Any infill greater than 50% but less than 100% converts to a 50% infill with a greater extrusion width. This may not always be a good idea: Beads wider than nozzle shoulder may not print so well. Not that I've ever had a compelling reason to make an infill between 50% and 100%, but just wondering why that is.
The paths are laid out on a grid with "extrusion width" spacing. So I get integer divisions for native infill density: 1/1, 1/2, 1/3, 1/4, etc. The interface paths get some special treatment to be able to get an arbitrary angle and stride, but standard infill is based on a grid.
lonesock wrote:
The paths are laid out on a grid with "extrusion width" spacing. So I get integer divisions for native infill density: 1/1, 1/2, 1/3, 1/4, etc. The interface paths get some special treatment to be able to get an arbitrary angle and stride, but standard infill is based on a grid.
lonesock wrote:
[8^) OK, it's in my working build, so you will have it soon (3 bugs left on my ToDo list!). I looked into dragging the model tabs around to change the order: it's definitely possible, just not sure how trivial. Once I fix the bugs I'll try to add it in.
Jonathan, is it a big deal to add "Avoid Crossing Perimeters"? I'm printing small text against the build plate and sometimes there is a little stringing of the surrounding solid infill when crossing over the text and for translucent text I can see the stringing. This is happening on the first layer which gets squished against the build plate. I'm printing the text at 5 mm / min and 10 mm / min so I'm not sure how effective the wizards can be to minimize stringing at those speeds. I dialed in my extruder steps and printed the calibration cubes adjusting the flow tweak accordingly. There's a lot of variables here, like how much the first layer is squished plus sometimes the solid infill extruder seems to clip a tiny speck of the text sticking up (maybe from the z-lift I'm trying now?) and knocks it off onto itself. As I mentioned I'm trying z-lift, but that presents problems of it's own.
Anyways there's a lot of variables at play here where "Avoid Crossing Perimeters" could just solve the problem.
That function is planned for the next release. I already have some A* pathfinding code written and in KISSlicer, but it isn't as simple as I would like, so I pushed it back till the next release.
lonesock wrote:That function is planned for the next release. I already have some A* pathfinding code written and in KISSlicer, but it isn't as simple as I would like, so I pushed it back till the next release.
thanks,
Jonathan
Great thanks, you'll do all the work and I'll get all the credit when my prints come out nice... just kidding of course, I recommend Kisslicer over all the other slicers.
So how was Flow Gain functionally different from the new Support / Object Interface Width? Printing with it now using 80% of my Extrusion Width (normally used 80% gain).
inventabuild wrote:I recommend Kisslicer over all the other slicers.
layerone wrote:So how was Flow Gain functionally different from the new Support / Object Interface Width? Printing with it now using 80% of my Extrusion Width (normally used 80% gain).
I think it doesn't work like that now, it needs to be multiples of extrusion width, IIRC (otherwise it's made multiple of extrusion width)… But let's hope someone will correct me.
layerone wrote:So how was Flow Gain functionally different from the new Support / Object Interface Width? Printing with it now using 80% of my Extrusion Width (normally used 80% gain).
I think it doesn't work like that now, it needs to be multiples of extrusion width, IIRC (otherwise it's made multiple of extrusion width)… But let's hope someone will correct me.
Humm, this is getting confusing. I thought Stride, Width and 1st Width were all in mm - the latter certainly is (according to tooltip). Stride may have to be a multiple of width, but not sure...