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?
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).
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.
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.
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.
