KISSlicer 1.6 Beta Bug Reports

[Dreide]

FIRST LAYER HEIGHT

hi, i've always 0.3mm of thickness for the first layer, I've try to change:
-layer thickness
-1st
and the three values on "printer hardware" tab..but the thickness dosen't change, is a bug?

p.s. i have the latest version, beta 1.6 2.4

From what I've seen Printer/Hardware/Bed Roughness + Style/LayerThickness = Style/1st Layer Thickness. 1st Layer Thickness and Bed Roughness appear to be two different ways of saying / achieving the same thing.

I think there is a subtle difference between the two. Bed Roughness makes the 1st layer accordingly thicker without re-slicing, i.e., the model will be nominally a bit higher than with Bed Roughness = 0. Whereas 1st Layer Thickness will be taken into account already for slicing, which is why changing the 1st Layer Thickness setting requires re-slicing the model.

[pjr]

I think there is a subtle difference between the two. Bed Roughness makes the 1st layer accordingly thicker without re-slicing, i.e., the model will be nominally a bit higher than with Bed Roughness = 0. Whereas 1st Layer Thickness will be taken into account already for slicing, which is why changing the 1st Layer Thickness setting requires re-slicing the model.

Yes, and for those of us whose printers have a MIN_Z value built into firmware (to prevent heat damage to the PEI sheet), it means that we simply have to set a first layer thickness in style rather than having to change bed roughness for (potentially) every print.

Peter

[inventabuild]

I think there is a subtle difference between the two. Bed Roughness makes the 1st layer accordingly thicker without re-slicing, i.e., the model will be nominally a bit higher than with Bed Roughness = 0. Whereas 1st Layer Thickness will be taken into account already for slicing, which is why changing the 1st Layer Thickness setting requires re-slicing the model.

Also, if 1st Layer Thickness is greater than Layer Thickness and Bed Roughness > 0 then 1st Layer Thickness + Bed Roughness = Total 1st Layer Thickness.

[Beefeater]

I'm working on #1 right now.

For #2, can anyone tell me if *all* BfB & CubeX firmware uses [seconds] instead of [milliseconds] for G4 Pxxx? I am working on a new Printer Profile Wizard and would like to know so I can properly initialize a setting telling KISSlicer how to scale the G4 command.

#3 - for the raft the paths have to be integer multiples of the extrusion width. I will change that for the 2.0 release, but I'm planning to leave it for this 1.6 release.

thanks,
Jonathan

Hi Jonathan, sorry I only saw your post just now. Thank you for fixing the problem so quickly! Peter, I think you can strike the "MinLayerTime" and "G4 Pnnn" bugs from the list at the top of this thread, as they have been confirmed resolved in beta 3.1.

Out of curiosity, could anyone still running BFB electronics please raise your hand? I have a couple small things I'd like to ask for, but if I'm the only one on BFB, I'll just write a post-processing script instead.

Boris

[pjr]

Peter, I think you can strike the "MinLayerTime" and "G4 Pnnn" bugs from the list at the top of this thread, as they have been confirmed resolved in beta 3.1.

Boris. Thanks; it's hard keeping up at times. removed from summary.

Peter

[Beefeater]

Printing a 1" diameter ball (for clarity, with no raft and no support). Low layers of the ball are overhanging, so Kisslicer slows down the perimeter bead to meet the "flow rate that the fan can fully cool" limit. But it does not slow the extrusion, at least not on BFB. Nor does it turn on the fan. See attached example at Z=3.35. So the perimeter bead comes out nearly twice too wide.

Seems like an easy fix: My Rapman 3.1 would be happy to change extrusion rate mid-path, if asked. Just issue M108 Snnn with new deci-rpm without stopping the extruder. If M227 destring is active, it will _NOT_ be triggered. This same trick can be used to implement jumps without destring, e.g. jumps shorter than MinJump. Just use M108 S0 instead of M103 and then M108 S<whatever> instead of M101. Can't vouch for any firmware other than my own though.

Boris

[lonesock]

Printing a 1" diameter ball (for clarity, with no raft and no support). Low layers of the ball are overhanging, so Kisslicer slows down the perimeter bead to meet the "flow rate that the fan can fully cool" limit. But it does not slow the extrusion, at least not on BFB. Nor does it turn on the fan. See attached example at Z=3.35. So the perimeter bead comes out nearly twice too wide.

Seems like an easy fix: My Rapman 3.1 would be happy to change extrusion rate mid-path, if asked. Just issue M108 Snnn with new deci-rpm without stopping the extruder. If M227 destring is active, it will _NOT_ be triggered. This same trick can be used to implement jumps without destring, e.g. jumps shorter than MinJump. Just use M108 S0 instead of M103 and then M108 S<whatever> instead of M101. Can't vouch for any firmware other than my own though.

Boris

Thanks. Making it work under BfB / CubeX-style firmware is on my todo list as well. Preload also fails under that type of firmware. When I change extruder RPM mid-extrusion it triggers a destring event automatically. So I need to manually do primes and retracts instead of relying on the firmware's destring. I also had trouble getting the extruder to run backward while moving the head around (which is a required behavior for the end of a Preloaded path)...I may have to do a 1/2-coast style modification for BfB. [8^/

thanks,
Jonathan

[Beefeater]

My Rapman 3.1 v. 4.2.1t most definitely does _NOT_ trigger a destring when extruder RPM is changed on the fly. I tested multiple times. It's a little disheartening that a simple solution is available on my firmware but I can't have it because it wouldn't work on some other firmware... Would it be possible to maybe put enough comments in the code so I can write a post-processor to fix? Right now, it's hard to tell whether kisslicer wants to slow extrusion but doesn't know how (e.g. overhang) or is deliberately making a wider bead (e.g. crown). Of course adding a comment is probably as much work as adding M108's...

[lonesock]

We'll get there (at least most of the way [8^). It's on the "ToDo for 1.6 Release" list. We may need to take this portion of the development into a different thread where I can more frequently update builds for just this issue. What OS are you running?

thanks,
Jonathan

[Beefeater]

We'll get there (at least most of the way [8^). It's on the "ToDo for 1.6 Release" list. We may need to take this portion of the development into a different thread where I can more frequently update builds for just this issue. What OS are you running?

Win64. But it isn't as urgent as all that. Now that I've figured out the problem, I can turn off the overhang flow limit and wait for the regular 1.6 release. As long as it's in 1.6... Thank you, Jonathan!

About Preload. I experimented with ooze some months back. I am sure you've been more thorough than I have, but maybe my observations could still be helpful. I used a test pattern like in the attached picture. It has straight lines where extrusion stops in the middle of the line while travel continues, then starts again in the middle of the next line. This shows quantity and duration of ooze after extrusion stops, as well as quantity and duration of shortfall when extrusion restarts (which is ooze's twin brother and could cause problems also).

Intuitively, from a linear elastic model, one expects exponential decay with time constant determined by viscosity, Young modulus, channel geometry, etc., and total ooze amount proportional to flow rate prior to the stop. But what I saw was quite different:
(1) Slow ooze continues for a very long time ~15s.
(2) At low flow rates, amount of ooze is almost independent of original flow rate.
(3) At high flow rates, something like the expected exponential behavior seems to emerge, with ~1s time constant, adding to the slow ooze observed at low rates.

In my particular setup (Rapman 3.1 extruder / MakerBot 0.4mm nozzle / ABS at 240C) the "high" flow rates started at ~4mm^3/s. My absolute maximum flow rate is ~12cm^3/s, above which the drive mechanism begins to skip.

I conclude from this that traditional "wipe" and "coast" strategies are useless, since you can't out-wait the 15s slow ooze. (Disclaimer: Rapman extruders are of quite unusual design, this may not be true on other printers.) Destring works well, but should be tuned to the flow rate: specifically, "suck" tuned to the flow rate _prior_ to the jump, to relieve chamber pressure, and "prime" tuned to the flow rate _after_ the jump, to build up the necessary pressure. Which is just what BFB firmware allows you to do by inserting M227 before M101 for each path.

BFB still has two major limitations, though. First, strings always appear at high jump speeds because the pressure is not relieved quickly enough. Second, BFB has built-in speed ramp generation for travel speeds over 12mm/s. So if the command speed is, say, 40mm/s, there is over-deposition at both the start and the end of the path owing to gradual acceleration/deceleration. If the path segment is short (e.g. when tracing a curve), command speed is never reached and there's over-deposition everywhere. I suspect there are other printers out there that implement speed ramps, and Kisslicer's current Preload algorithm might not work well with any of them. Something to keep in mind.