Slic3r seems to be printing worse and worse

I'm having trouble recently with Slic3r. After switching to my first new roll of filament, I've never been able to get great prints. However, I just tried KISSlicer for the first time last week, and the prints are much, much better. This tells me it must be at least partly a software issue.

I'm running a printrbot plus, with a heated bed (with aquanet hairspray) and modified z-nuts to reduce z-wobble. I'm printing in ABS with 3mm grey filament. My machine's X, Y, Z, and extruder are calibrated and really close to dead on.

I'm on a Macbook running Lion using MacPronterface. I have scli3r9.7 (which I've used exclusively until last week), scli3r9.8, and KISSlicer1.0.9 installed. I use the same config settings for both Slic3r versions.

I've made a bunch of test prints of a simple thin-walled cube, with a rounded corner.

What's weird is that I felt like I was getting better prints a few days ago, but now can't replicate the results with slic3r. Before I was getting fairly good prints with bumpy spots here and there from slic3r9.7.

I guess my main question is where to go from here with refining slic3r considering the KISSlicer prints look so much better. I like the slic3r interface and would prefer to stick with it. What am I doing wrong here?

Thanks

Edited 1 time(s). Last edit at 01/30/2013 10:11PM by blake.

Here's the last KISSlicer config file, I reached the maximum attachments in the last post.

Thanks

Sorry to keep posting, but maybe this piece of the puzzle will help. I was able to replicate my better (but not great) previous results with Slic3r by checking "randomize start points". Clicking this gives a much better print than without, but leaves bumps all over the surface, and less smooth layers. In Repetier-Host Mac 0.51, you can see clearly the striations that occur on the actual print.

The other prints from the above post look fine in Repetier-Host. All four of these prints were done one after another within two hours in one sitting, and 10 others from the same STL have been done in the last day. I don't think the variation in these prints is from changes in the hardware.

Hello!
Your report is very interesting as a comparison exercise. At a first glance I can notice the following differences between the G-code files:

- in the KS one I see no retraction (you can disable it in Slic3r by setting retraction length to zero)
- in the KS one I see a 2.5mm lift on Z change (you can enable it in Slic3r but it only works when retraction is enabled as well, but I honestly do not see how lift helps in this kind of print)
- it looks like you didn't enable cooling on Slic3r, as it's printing at 40mm/s while KS has cooling enabled and prints at ~11mm/s
- your custom G-code sets some jerk and acceleration limits, as well as E steps; however it looks like in KS it is being emitted all in one line, thus commenting everything. your custom E steps, jerk and acceleration are thus applied with Slic3r but not with KS. this might make a great difference

I look forward for your feedback about these differences.

Okay, I've printed four more testcubes to address some of the variables you've listed.

1. Print sliced with KISS with one mm of retraction (same length retraction as Slic3r).
2. Print sliced with Slic3r9.8 at 10mm/sec speed, with no random starts, and 1mm of retraction.
3. Print sliced with 9.8 at 10mm/sec, with random starts, and no retraction.
4. Print sliced with 9.8 at 10mm/sec, with random starts, and 1mm of retraction.

Let me address your list of items to look at:

I set KISS to no retraction because with 1mm of retraction it fails to print one side of the cube. I think this is because it retracts more (or in a different way?) than slic3r, and after the first layer fails to print (because too much plastic has been retracted), the rest of the layers fail to stick. With Slic3r, I need retraction or prints come out stringy, as seen in the third print.

I looked around in the KISS settings but I see no z-lift on retraction setting, or noticed it. I did notice the .25mm lift on layer change which was recommended to settle the z-axis against gravity when starting a new layer to improve accuracy. You can see the settings in the image grabs of KISSlicer.

I didn't enable cooling in Slic3r because I have no fan. In KISS I have it set to fan always off, even in the previous prints.

I looked at the gcode between the slic3r and KISSlicer prints, and both have my custom gcode prefixed appropriately. I even have a screen grab of the KISS code in Repetier-Host Mac, and you can see that it isn't commented out. I also opened the gcode files in textedit (a mac program), and it was correctly uncommented.

Results:

Slowing down Slic3r prints to 10mm/sec helped them a lot but there are still bumps with the random start points on, and the surface is still rougher, seen in the actual print and in Repetier-Host. With random starts turned off, the surface is definitely smoother, in RH and in the actual print.

In terms of speed, I feel like 10mm/sec is extremely low, and I should be able to get better results at 40. I set KISSlicer in the settings to 40mm/sec, but for some reason it is still going slow. I'm going to try to speed it up to see if it is my hardware that is causing an issue, or software. But the surface is definitely not smooth when using random starting points.

Any ideas?

Here are the .g files for the four prints above. I ran out of attachments on the last post.

Thanks for helping figure this out.

In KISSlicer you need to set prime to the same value as suck, which is why you are seeing the missing side, currently you are retracting plastic but not returning it to the same position after the move.

Hello blake,

thanks again. I'll look at things more in depth later, but for now I wanted to say that the cooling logic in Slic3r does not just control fan: it adjusts print speed too, according to the configurable threshold. For very small objects like this one, it will slow the print down. I'm pretty sure that's just the same KS is doing. Yes, 11mm/s is pretty low but it's probably the only good way to print such a tricky calibration object. You do not need to set this manually: just keep the cooling option enabled (it's enabled by default in factory settings).

The slow_not-random one looks infact good. I just do not understand very well why those crackles appeared.

Regarding, start G-code, I'm attaching a screenshot of the testcube_KISS1.0.9_01-30a.g file as I see it in a text editor: as you see, the custom commands are all concatenated on a single line, and thus totally ineffective. It may be an issue of newlines, but I think it needs to be fixed somehow as we are not sure that they are being sent to the printer.

Polygonhell and a private message both pointed out that when using retract with KISS, you also then need to prime. I will try it this evening. I should have done that earlier, but didn't because in Slic3r I retract 1mm without adding extra length on restart (or prime with KISS). I messed around with these settings a while ago, and found that this was the best for my machine with Slic3r.

Sound, thanks for your reply. I will do some more tests this evening, and I will turn on cooling in Slic3r to slow down the prints. I figured out last night that what was causing my KISS prints to print at 11mm/sec or so was that I had minimum layer time set to 10 seconds. I lowered that variable to 3, and my prints sped up to the expected 40mm/sec speeds. I also saw a drop in quality from the KISS prints at those speeds (the speed at which Slic3r had originally been printing).

Also, the cracking on slow_not-random is from peeling it off the bed, and breaking the layers in the process. I should have stated that in my previous posting. I just started using hairspray to stick prints down, and it sticks hard.

In fact, I think slow_random also looks really good. The bumps at the starting locations are pretty small and don't stick out much. But, the surface is definitely rougher than without random starting, all other variables equal, and this is also what I'm trying to get at.

Finally, The prefix in the gcode for these prints is what sets my E-stops and X Y Z calibrations for the printer. My machine shipped with different values which I calibrated. I will check later to see if I'm right about this, but if I took it out, the machine would revert to its internal settings and would not print the squares at the right size or with the correct amount of filament. Since the squares printed from the KISS files are dead on at 30mm square, and look to be printed okay, doesn't that mean the prefix must be correct in the gcode? I think you forgot to add your screenshot, so I can't see what you're looking at, but I just now opened the KISS gcode in Mac OpenOffice 3.3 and it also shows the prefix uncommented.

Thanks for all the assistance. It is really helping to work out these problems I've been having.

Edited 1 time(s). Last edit at 02/01/2013 09:10AM by blake.

Well, I don't know whether those E-steps, acceleration and maxjerk are right or not - I was pointing out that they were differently applied in the two G-codes, thus possibly compromising the comparison. They indeed override your firmware defaults, so you are right in using them to adjust the defaults. Also note that they last until you reset your electronics board so if you change them in some prints but do not set them explicitely in other prints, you never know what settings were actually used unless you reset your electronics manually before each print.

Er... it would be good idea to mark this as [SOLVED] if you feel like it is

Here are two more test cube prints:

1. KISS print using retract with prime, as suggested.
2. Slic3r9.8 print with cooling and random starting.

The KISS print looks great and the prime works great. Using cooling with Slic3r really helped to make the prints a lot nicer. It works similar to KISSlicer in slowing down the print head on small layers. Great. And the bumps where the random layers start are small and not a huge deal anymore. Everything seems to be working out, and I appreciate the help pinning this down.

All along though, I have noticed in both the print and the Repetier-Host simulation, that when using random layer starts in Slic3r, the sides of the cube are no longer flat. While it is slight, you can line up the actual print with the RH sim, and see that the patterns match. I hesitate to close this thread before figuring out why that is the case. Again, without random starting, the roughness goes away, and it is noticeable in the actual print. Also, because this is only a Slic3r problem, we can set aside the discussion of whether or not the gcode prefix is working in KISS or not. From everything I can see, it is working. But I think it is irrelevant to the "rough wall with random starting" issue.

Should I open a new thread to address that specific issue and close this one?

Thanks for the help.

Edited 1 time(s). Last edit at 02/02/2013 05:26PM by blake.

So, here I am.

I had a close look at the issue and wanted to check whether the G-code was actually misaligned or not. So I generated a simplified test G-code file (attached) that just lays down four segments per layer, with the same exact coordinates; however layers are randomly rotated just like the randomization feature does in Slic3r.

Since all layers use the same coordinates and same flow I would expect a perfect smooth rendering effect; however it looks like the position of the start/end point causes different shapes in that corner and different shades along the nearby segments. When this happens in random corners, the effect looks very inconsistent.

This shows that corners are truncated in a different way (no mitering) when start and end meet:


Same comparison from top view (this shows the different shading):


Overall result showing the inconsistent effect:


Regarding the difference in actual printing I'm pretty sure it's caused by the extra travel caused by the randomization feature. This rendering shows that travel moves happen on the perimeters and I expect this has a noticeable effect on such a weak and heat-critical object - and your picture confirms it.


This travel-along-perimeters doesn't usually happen when printing with more than one perimeter and/or with some infill. I'm considering turning the randomization off by default.

Let me know your thoughts and again, thank you for such a detailed report that was an interesting test case.

Edited 1 time(s). Last edit at 02/05/2013 05:13AM by Sound.

I'm attaching the test G-code file just in case.

This is the confirmation from the Repetier-Host author: [github.com]

Sound, thanks for all the time and help solving these problems. Your research into this is detailed and really interesting. The prints I'm getting now are better than before, and working on these test prints has helped me pinpoint problem areas to work on further.

I think I'm set in terms of this thread, and I'll mark it as closed. I'm going to be doing more test cube prints, and I'll let you know if I encounter any other interesting information with regards to this issue.

Edited 1 time(s). Last edit at 02/04/2013 06:21PM by blake.

Ahh, happy to find this thread!
That rough cornered look has bugged me and I thought it was a printer issue. (I'm new to all this)
Thanks.