kisslicertalk.com

The pink coloring is showing that the paths are unsupported (or on top of interface material) so they slow down

hacker wrote:On mac things sometimes look like this:

Screen Shot 2017-08-18 at 21.48.59.png

Just parts of the text are wiped out. I don't have a way to reproduce it, just have kisslicer running for a while, slice this, slice that and then it happens.

Once this happens, does minimizing and restoring the main KISSlicer window work?

thank,
Jonathan

lonesock wrote:

hacker wrote:On mac things sometimes look like this:

Screen Shot 2017-08-18 at 21.48.59.png

Just parts of the text are wiped out. I don't have a way to reproduce it, just have kisslicer running for a while, slice this, slice that and then it happens.

Once this happens, does minimizing and restoring the main KISSlicer window work?

thank,
Jonathan

Nope, exactly the same corruption is preserved (just tried).

And when I change style only these visible areas are updated.

OK, I'll try to use my Mac build some more, see if I can duplicate / fix it.

thanks,
Jonathan

lonesock wrote:OK, I'll try to use my Mac build some more, see if I can duplicate / fix it.

Thanks. It's not that I complain, I actually know my profiles and prefer settings window for details, but it does seem wrong

Could you please also attach a KISSlicer Project file?

Sure, here it is.

On the Mac version, the setting on the right side is distorted.
This defect started when the display was swapped left and right.

The pink coloring is showing that the paths are unsupported (or on top of interface material) so they slow down

Ok, understand.

Changing the interface Zgap did not reset the generated path if the new value is smaller than minimum layer thickness.
It Seem it reset the path only if l.t. is in mm, and the new Zgap is equal or twice of l.t.

Narrow walls seem not to print at correct width.

Printing two 10mm x 10mm boxes, one with 0.6mm wall width, the other 0.65mm. The STL files are ASCII, so can directly verify wall thickness. Extrusion width (calculated in the usual way, (7.41mm^3/rev)*RPM/(feed*layerheight)) is 0.54mm for the first box and 0.60mm for the second, i.e. ~10% smaller than expected. Same result when Style set to 0.5mm extrusion width or to 0.6mm extrusion width. Extrusion width is correct elsewhere. .STL and .BFB attached.

Also, although the wall paths are straight lines, Kisslicer breaks them up into a zillion short segments, and many more segments in the 0.6mm box than in 0.65mm. I don't suppose it's a bug (though it could cause issues in printers that generate acceleration ramps in firmware), but I'm just curious why that is.

Boris

Hi!

I've attempted to print this model using Stepover Control twice, both times around layer 210, it will inexplicably begin moving toward positive X and Y. As if it were homing those positions. I'm currently reprinting it without variable layer height to see if that is the issue. I've printed with variable layer height numerous times prior to RC1 with no issue, and 14 hours is a long time to go back to a previous version to test. Although if I need to, I will.

Included is the gcode used, as well as my layer settings.

I'm printing with a Maker Select v2, using a Raspberry Pi w/Octoprint.