Favorite Slicer?

Don't trust the time. KISSlicer code has lots of comments and stuff in it that throws off the time calculations. I just did a print that said 1hr and it was less then 20m

jbernardis Wrote:
------------------------------------------------
> - on the Materials tab I don't understand what
> to do about the warm-up factor. Does this imply
> that you may insert some waits in the gcode

This is for dual extrusion so it knows what temperature to set the idle extruder so it does not drip every where. I you are using a single extruder just ignore it.

> - there is very limited fan control - always on
> or off, or on for perimeters. What about on for
> small layers?

As I have said repeatedly everyone should be trying the beta or RC1 not the really old release that is lacking features.

> - on the extruders tab, what is mm/rev. I
> wouldn't know how to measure that - is it inflow
> or outflow - and even if I could, it should have
> no bearing on the resultant g code.

Again you are using the old release that mentions many things that relate more to old RepRap and BFB commands which confuses most people. If you use the beta or RC1 it does not mention RPM anywhere.

> I also don't like how/where the parameters are
> stored. The settings from the "Advanced Settings"
> dialog box are stored in 3 ini files right in the
> KISSlicer directory. The settings from the main
> screen are stored off in a kisslicer.prefs file in
> some arcane directory that is OS dependent. This
> is only an issue to someone like me who wants to
> integrate the slicer into their host program, but
> it seems awkward.

I am not sure what the advanced tab is since it does not exist in the latest versions but if it is the stuff only available in the Pro version you should never need to adjust them for any reason. I like where the configs are saved because I have a separate folder for each machine so I can have the settings for each machine separate and not have to load anything except the program in the correct folder. But I think that all configs should be one file because the way Kisslicer and Slic3r try to separate them is wrong. If you adjust the layer height it effects settings under all the categories like speed and temp.

>
> Perhaps the biggest issue I had was with printing
> speed. I have a relatively small STL file - 3
> clips that go around a 15 mm aluminum extrusion.
> I sliced and printed with skeinforge and the print
> time was 15 minutes. I then sliced in KISSlicer,
> and the time estimate for the resulting g code was
> just under 5 hours. I didn't let the print
> finish. I don't know if it was really going to
> take 5 hours, but it was going to be significantly
> longer that the skeinforge job. Admittedly, I
> didn't change any of the pre-populated speed
> values, and I sliced with the precision at 50%,
> but even with that, I don't think the difference
> in print times should have been so dramatic.

What told you that? Not Kisslicer? I have found its estimates off but never seen results like that and from all the video tests comparing it with SF and Slic3r it was always the fastest because it retracts less often and has better path planning.

If I were you I would test the new version and remember it is not a branch of RepRap so it did not follow the same path that all other RepRap slicers took. He did things different and I believe that is why it works better while confusing people. I personally do not think the normal RepRap promoted methods of doing things is always right and sometimes completely wrong.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Where would I find this latest version. I went to Kisslicer.com. I thought that would be the most current. I just searched again for it, and that seems to be the only site to come up from which I can download. BTW - it's version 1.0.9.7 dated 12-Jun-2012, so it IS fairly old. If there is a more recent version available I'd love to try it.

I figured some of those parameters were for older style extruders. I basically ignored them and got good results.

When I said Advanced Settings, I meant the settings dialog box with the 5 or 6 tabs. That is what it is called in the menu - at least in the version I tried.

The beta and RC1 releases are only available from the forum.

Beta [kisslicer.com] which is only Linux because Windows and Mac are onto RC1 which is available [kisslicer.com]

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

I tried Kisslicer for the first time this week and am amazed by the results. I've been spending so much time trying to calibrate my printer with Slic3r to no avail. Kisslicer just seems to work. Not sure why but getting the first layer right is so much easier too. And....no more boogers! I was able to print the high-res Yoda with almost no issues and without support material (I couldn't get some of the support stuff to stay so I turned it off). Now, if I can just figure out how to get things off the print bed as things seem to be sticking much better too. I broke Yoda's neck trying to get him off the bed..oops. Looking forward to playing around with it some more this weekend.

Cheers,

KDog

get a cricut spatula. [www.ebay.com]

does anybody else have issues with slic3r not liking certain .stl files? It seems about 50% of the .stl files I create with SolidWorks 2013 create errors in slic3r. I'm currently experimenting with kisslicer but results have nt been as good as slic3r although has nt thrown up an error at all yet. I guess I'll need to register on the kisslicer forum to download v1.1.0 as cant see how to download it otherwise?

Most of the files I download from thingiverse need to be repaired before slic3r will work (I've been using netfab cloud - great site). Haven't used kisslicer enough to know if errors appear as often. You do have to register in order to see the download links for the kisslicer beta.

Get netfabb studio basic it is free. You will need to run it on all files exported from Solidworlks. Kisslicer may not complain about the files but you may get weird results on the print. Most thingiverse files also need repaired also.

Kisslicer will slice anything but it will not always give you the results you were expecting if the model has issues. It highlights the problem areas of the model with colored edges and provides a color key explaining what it is seeing and you may need to repair those spots manually because netfabb does not really repair files as much as it patches them in really bad ways that are an issue themselves. Netfabb has no issue with inserting degenerate or zero area faces which are problems for Kisslicer.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Quote

does anybody else have issues with slic3r not liking certain .stl files? It seems about 50% of the .stl files I create with SolidWorks 2013 create errors in slic3r.

It's an issue with how SW generates STL files. If you feed them through cloud.netfabb.com it will fix the errors.

Cool thanks, have downloaded netfabb basic and will try the cloud as well.

So I got the beta release of kisslicer 1.1.0, and it's MUCH better than before. I didn't change too many of the starting parameters, but here is what I found:

The object I am printing is the X motor bracket I designed for an aluminum extrusion printer I am making. It's a decent sized object. When I slice it with kisslicer, kisslicer itself gives me time estimates that range from 4:48 to 8:17 (hh:mm) depending on the precision setting. I went with a middle of the road precision of 50% and the time estimate from kisslicer was 5:18.

When I imported this into pronterface, it gave me a time estimate of 12:54, and when I imported into my own host software which uses the pronterface underpinnings (gcoder.py) it game me an estimate of 13:20. The object is actually printing so I don't know the actual print time, but based on my host software's constantly revised ETA, it looks like it's going to take 5:10 - so obviously I need to look at the gcoder.py code. It seems to me that the big difference in print time I am seeing between this slicer and the others is due to the perimeter times. kisslicer seems to have the strategy to go slow on the perimeters. So in about 3 hours, I will have a good look at the object to see if the time sacrifice was worthwhile. I can always speed it up.

There ARE two things that I have to bring up:
1) on every layer, the outside perimeter starts at exactly the same point. There's quite a blob there right now. I left the retraction (suck) settings alone, but they might need more work.
2) for some reason, the first layer height was 0.450mm. My layer height setting is 0.2mm. I use this same value in slic3r and skeinforge, and my first layer is at 0.18 (because of my settings in bottom plugin, etc). I can't find a setting that would make the first layer so high, except perhaps for the skin thickness (which is set at the default 0.8).

I'm encouraged by what I see, and I'll keep experimenting

jbernardis Wrote:
-------------------------------------------------------
> There ARE two things that I have to bring up:
> 1) on every layer, the outside perimeter starts at
> exactly the same point. There's quite a blob
> there right now. I left the retraction (suck)
> settings alone, but they might need more work.

Oh a few hours to early. He released RC2 (also in Linux) and it now has a jitter function as well as a control for the depth of the seam. Try the seam at 0.5 and the jitter about 90 and see how that works out for you.

> 2) for some reason, the first layer height was
> 0.450mm. My layer height setting is 0.2mm. I use
> this same value in slic3r and skeinforge, and my
> first layer is at 0.18 (because of my settings in
> bottom plugin, etc). I can't find a setting that
> would make the first layer so high, except perhaps
> for the skin thickness (which is set at the
> default 0.8).

Its the bed roughness setting. It adds that amount to the layer height for the first layer.

>
> I'm encouraged by what I see, and I'll keep
> experimenting

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Thanks - I didn't realize there was a newer one out there. That's what it means to be on the bleeding edge I guess.

Thanks too for the bed roughness setting. It was indeed 0.25 and it would account for the higher first layer. Any reason not to set it back to 0? I've never had an issue with unevenness of the bed (and 0.25 seems like a large compensation factor anyway)

I also found the bug in the time estimation. It wasn't actually in the gcoder.py file, but in a separate file. I merged it into gcoder.py when I adapted the code for my purposes. Anyway, for gcode lines that change the speed, but have no movement (eg. "G1 F30000") it would add in the time it took to accelerate from the current speed up to that speed and then decelerate the same amount. Once I fixed that logic, the time estimation was accurate

jbernardis Wrote:
-------------------------------------------------------
> Thanks - I didn't realize there was a newer one
> out there. That's what it means to be on the
> bleeding edge I guess.

Right now for sure. But I think after the release it will be a few months before we see another Alpha release if my impression of his process is correct.

>
> Thanks too for the bed roughness setting. It was
> indeed 0.25 and it would account for the higher
> first layer. Any reason not to set it back to 0?
> I've never had an issue with unevenness of the bed
> (and 0.25 seems like a large compensation factor
> anyway)

Again I think this is a result of its origin in BFB and dual head machines. they seem to use a raft all the time and don't really care if the bed in level so they just compensate on the first layer. Where as in RepRap we have gotten used to printing the first layer at close to the normal layer height. I personally have it set to 0 and it acts as expected. Also you will want turn of Z-Settle as well unless you have a bed that moves downwards and does not have any antibacklash system (like BF.

>
> I also found the bug in the time estimation. It
> wasn't actually in the gcoder.py file, but in a
> separate file. I merged it into gcoder.py when I
> adapted the code for my purposes. Anyway, for
> gcode lines that change the speed, but have no
> movement (eg. "G1 F30000") it would add in the
> time it took to accelerate from the current speed
> up to that speed and then decelerate the same
> amount. Once I fixed that logic, the time
> estimation was accurate

Nice I could never get Pronterface to give estimates that were even close to the real time so I stopped looking at it.

Edited 1 time(s). Last edit at 03/25/2013 08:07PM by Sublime.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver